-
Notifications
You must be signed in to change notification settings - Fork 54
meta-refkit-extra: add new layer and computer vision demo content there. #130
Conversation
|
|
||
| # Demo layer, disabled by default. To enable, uncomment the line below | ||
| # and increment LCONF_VERSION by one. | ||
| # REFKIT_LAYERS += "##OEROOT##/../meta-refkit-extra" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect that this comment might become misleading once bblayers.conf.sample turns into conf/bblayers.conf. A developer editing that bblayers.conf the might uncomment the line and bump LCONF_VERSION, which wouldn't be right.
Do we need this change in bblayers.conf.sample at all?
A developer who wants the extra layer can do "bitbake-layers add-layer ".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I'll remove the comment.
|
On Wed, Apr 26, 2017 at 11:02 AM, Patrick Ohly wrote:
Do we need this change in bblayers.conf.sample at all?
A developer who wants the extra layer can do "bitbake-layers add-layer ".
+1
|
76f2ea5 to
fc7c08a
Compare
66effcf to
3af337f
Compare
|
@mythi yes, added now. The only "refkit-affecting" change is the OpenCV Python 3 dependency change. |
|
@ipuustin thanks, this looks good to me. Let's take it once the documentation is finished. |
a00ab01 to
52f2ac1
Compare
|
Ok, rebased. The docs are now in ok shape. |
pohly
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So "refkit-extra.conf" is not meant to be a distro configuration? Currently it is, because it is placed in conf/distro of a layer.
Better move it to conf/distro/include. I would also squash the two commits introducing meta-refkit-extra.
Add meta-refkit-extra layer for storing demos and extra content. Have the layer initially in disabled state. Also add initial configuration. Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Pillow is a fork of PIL, Python Imaging Library. Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
ImageIO is a Python library for doing basic I/O operations for images. Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
The protobuf package didn't compile Python bindings. Add a new package which does that. Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
The goal is to have the computer vision stack to be scriptable by Python 3. Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
The recipes are originally from (non-maintained) meta-convnet layer. Patch Caffe to compile the Python bindings with Python 3. Also change the image IO libary away from scipy-image, so that we don't have full matplotlib and graphical environment as runtime dependencies. Then add custom demo scripts. Many recipes are updated and customized. They probably don't work properly in anything else than 64-bit x86 environment. Also add package with a pretrained imagenet model. The model is a pretrained deep learning network for classifying based on the imagenet database. Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Pyrealsense contains Python bindings for librealsense. Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Added documentation for setting up pyrealsense and Caffe demos. Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
52f2ac1 to
2015b44
Compare
|
@pohly : ok, I did the changes you suggested. |
| @@ -0,0 +1 @@ | |||
| PACKAGECONFIG += "python" | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ipuustin Is this needed? IIRC you mentioned it's not needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's still needed -- it enables Python support in boost. We no longer need to select Python 3 by editing the user-config.jam file, because Python 3 support is now enabled as default if it's found. See difference to the previous iteration of the same file. https://github.com/ipuustin/intel-iot-refkit/blob/165b46149a2c5a58788b91d2cac97c394e567f14/meta-refkit/recipes-convnet/boost/boost_%25.bbappend
However, it's a good question if we should move the PACKAGECONFIG variable to the layer distro configuration file instead of the .bbappend file. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see. python isn't enabled by default. I got confused by what you wrote earlier: "The bbappend should not be needed anymore."
|
On Thu, 2017-04-27 at 21:43 -0700, Ismo Puustinen wrote:
However, it's a good question if we should move the PACKAGECONFIG
variable to the layer distro configuration file instead of
the .bbappend file. What do you think?
Yes, please move it.
One of the "Yocto Compatibility 2.0" criteria is that a layer must not
change the build result merely because it was added to bblayers.conf,
because adding or removing layers to enable or disable something is
awkward.
I intend to add an oe-selftest which calls yocto-compat-layer on our
layers.
|
|
On Fri, Apr 28, 2017 at 9:21 AM, Patrick Ohly wrote:
One of the "Yocto Compatibility 2.0" criteria is that a layer must not
change the build result merely because it was added to bblayers.conf,
because adding or removing layers to enable or disable something is
awkward.
Is the compatibility scope limited to adding/removing the layer? In order
to use the layer properly the user must change the config but is it so that
it does not count?
|
|
On Thu, 2017-04-27 at 23:38 -0700, Mikko Ylinen wrote:
On Fri, Apr 28, 2017 at 9:21 AM, Patrick Ohly wrote:
> One of the "Yocto Compatibility 2.0" criteria is that a layer must
not
> change the build result merely because it was added to
bblayers.conf,
> because adding or removing layers to enable or disable something is
> awkward.
>
>
Is the compatibility scope limited to adding/removing the layer?
Merely adding/removing must not have an effect.
In order
to use the layer properly the user must change the config
For "the config" = local.conf or the distro config, yes.
but is it so that
it does not count?
I'm not sure anymore what "it" is here.
|
|
On Fri, Apr 28, 2017 at 9:44 AM, Patrick Ohly <notifications@github.com>
wrote:
On Thu, 2017-04-27 at 23:38 -0700, Mikko Ylinen wrote:
> In order
> to use the layer properly the user must change the config
For "the config" = local.conf or the distro config, yes.
> but is it so that
> it does not count?
the mandatory local.conf change
|
|
I think @mythi means that this does not matter much because in order to properly use the layer, the user needs to do two things: add the layer and include the configuration file. This will anyway cause the build result to change. I like the concept of separating policy (configuration files) and mechanism (recipes), even though it makes |
|
PR here: #133 |
Add meta-refkit-extra layer for storing demos and extra content. Have the layer initially in disabled state. See https://lists.yoctoproject.org/pipermail/intel-iot-refkit/2017-March/000005.html for discussion.