| Message ID | 20200205130420.8736-1-kieran.bingham@ideasonboard.com |
|---|---|
| Headers | show |
| Series |
|
| Related | show |
Le mer. 5 févr. 2020 08 h 04, Kieran Bingham < kieran.bingham@ideasonboard.com> a écrit : > When developing and testing libcamera, the usual development model is to > compile and run one of the test or utility applications. > I like it. Be aware that it won't work for me. It only work if the build path matches run path, which isn't the case when cross compiling and exporting over NFS. Any suggestion ? > IPA modules are loaded by the IPAManager, from a system path, or by > parsing an > environment variable. > > Provide the build path to the library through a temporary storage in the > runpath of the ELF library strings table. This entry is stripped at > install > time, but allows us to identify the location of the recently compiled IPA > modules without the user having to manually declare paths to the build > system. > > Previously to this series the IPA tests would only be able to be run from > the > root of the build tree, due to the hardcoded path relative to that point. > Now > that the IPAs can be found from their build location, we no longer need to > provide this hardcoded path through the LIBCAMERA_IPA_MODULE_PATH for > tests, > and as a further consequence they can be run directly without requiring the > launch to be run from the top level of the build tree. > > Kieran Bingham (5): > libcamera: utils: Provide helper to get dynamic library runpath > libcamera: ipa_manager: Split path handling > libcamera: ipa_manager: Allow recursive parsing > libcamera: ipa_manager: Search the runpath for IPA libraries > tests: Remove IPA_MODULE_PATH environment variable > > src/libcamera/include/ipa_manager.h | 5 +- > src/libcamera/include/utils.h | 1 + > src/libcamera/ipa_manager.cpp | 111 ++++++++++++++++++++++------ > src/libcamera/meson.build | 1 + > src/libcamera/utils.cpp | 26 +++++++ > src/meson.build | 7 ++ > test/libtest/test.cpp | 4 - > 7 files changed, 126 insertions(+), 29 deletions(-) > > -- > 2.20.1 > > _______________________________________________ > libcamera-devel mailing list > libcamera-devel@lists.libcamera.org > https://lists.libcamera.org/listinfo/libcamera-devel >
Hi Nicolas, On 05/02/2020 14:03, Nicolas Dufresne wrote: > > > Le mer. 5 févr. 2020 08 h 04, Kieran Bingham > <kieran.bingham@ideasonboard.com > <mailto:kieran.bingham@ideasonboard.com>> a écrit : > > When developing and testing libcamera, the usual development model is to > compile and run one of the test or utility applications. > > > I like it. Be aware that it won't work for me. It only work if the build > path matches run path, which isn't the case when cross compiling and > exporting over NFS. Any suggestion ? Interesting (and painful) point. Ideally it would be a relative path, but the binary path (/proc/self/exe) doesn't always have to stay relative to the library path ... I wonder if I can get the library path at runtime... Time to dig into what else is in the _DYNAMIC table perhaps. Otherwise, I'm certainly open to suggestions from the list here ;-) -- Kieran > IPA modules are loaded by the IPAManager, from a system path, or by > parsing an > environment variable. > > Provide the build path to the library through a temporary storage in the > runpath of the ELF library strings table. This entry is stripped at > install > time, but allows us to identify the location of the recently > compiled IPA > modules without the user having to manually declare paths to the > build system. > > Previously to this series the IPA tests would only be able to be run > from the > root of the build tree, due to the hardcoded path relative to that > point. Now > that the IPAs can be found from their build location, we no longer > need to > provide this hardcoded path through the LIBCAMERA_IPA_MODULE_PATH > for tests, > and as a further consequence they can be run directly without > requiring the > launch to be run from the top level of the build tree. > > Kieran Bingham (5): > libcamera: utils: Provide helper to get dynamic library runpath > libcamera: ipa_manager: Split path handling > libcamera: ipa_manager: Allow recursive parsing > libcamera: ipa_manager: Search the runpath for IPA libraries > tests: Remove IPA_MODULE_PATH environment variable > > src/libcamera/include/ipa_manager.h | 5 +- > src/libcamera/include/utils.h | 1 + > src/libcamera/ipa_manager.cpp | 111 ++++++++++++++++++++++------ > src/libcamera/meson.build | 1 + > src/libcamera/utils.cpp | 26 +++++++ > src/meson.build | 7 ++ > test/libtest/test.cpp | 4 - > 7 files changed, 126 insertions(+), 29 deletions(-) > > -- > 2.20.1 > > _______________________________________________ > libcamera-devel mailing list > libcamera-devel@lists.libcamera.org > <mailto:libcamera-devel@lists.libcamera.org> > https://lists.libcamera.org/listinfo/libcamera-devel >
Le mercredi 05 février 2020 à 14:12 +0000, Kieran Bingham a écrit : > Hi Nicolas, > > On 05/02/2020 14:03, Nicolas Dufresne wrote: > > > > Le mer. 5 févr. 2020 08 h 04, Kieran Bingham > > <kieran.bingham@ideasonboard.com > > <mailto:kieran.bingham@ideasonboard.com>> a écrit : > > > > When developing and testing libcamera, the usual development model is to > > compile and run one of the test or utility applications. > > > > > > I like it. Be aware that it won't work for me. It only work if the build > > path matches run path, which isn't the case when cross compiling and > > exporting over NFS. Any suggestion ? > > Interesting (and painful) point. > > Ideally it would be a relative path, but the binary path > (/proc/self/exe) doesn't always have to stay relative to the library > path ... > > I wonder if I can get the library path at runtime... Time to dig into > what else is in the _DYNAMIC table perhaps. > > Otherwise, I'm certainly open to suggestions from the list here ;-) Note that meanwhile I can just set the env really, I'm a bit use to that anyway. GStreamer, GLib and Mesa (which are the kind of stuff I cross compile) all requires few envs already. > > -- > Kieran > > > > > IPA modules are loaded by the IPAManager, from a system path, or by > > parsing an > > environment variable. > > > > Provide the build path to the library through a temporary storage in the > > runpath of the ELF library strings table. This entry is stripped at > > install > > time, but allows us to identify the location of the recently > > compiled IPA > > modules without the user having to manually declare paths to the > > build system. > > > > Previously to this series the IPA tests would only be able to be run > > from the > > root of the build tree, due to the hardcoded path relative to that > > point. Now > > that the IPAs can be found from their build location, we no longer > > need to > > provide this hardcoded path through the LIBCAMERA_IPA_MODULE_PATH > > for tests, > > and as a further consequence they can be run directly without > > requiring the > > launch to be run from the top level of the build tree. > > > > Kieran Bingham (5): > > libcamera: utils: Provide helper to get dynamic library runpath > > libcamera: ipa_manager: Split path handling > > libcamera: ipa_manager: Allow recursive parsing > > libcamera: ipa_manager: Search the runpath for IPA libraries > > tests: Remove IPA_MODULE_PATH environment variable > > > > src/libcamera/include/ipa_manager.h | 5 +- > > src/libcamera/include/utils.h | 1 + > > src/libcamera/ipa_manager.cpp | 111 ++++++++++++++++++++++------ > > src/libcamera/meson.build | 1 + > > src/libcamera/utils.cpp | 26 +++++++ > > src/meson.build | 7 ++ > > test/libtest/test.cpp | 4 - > > 7 files changed, 126 insertions(+), 29 deletions(-) > > > > -- > > 2.20.1 > > > > _______________________________________________ > > libcamera-devel mailing list > > libcamera-devel@lists.libcamera.org > > <mailto:libcamera-devel@lists.libcamera.org> > > https://lists.libcamera.org/listinfo/libcamera-devel > >
Hi Nicolas, On Wed, Feb 05, 2020 at 01:49:11PM -0500, Nicolas Dufresne wrote: > Le mercredi 05 février 2020 à 14:12 +0000, Kieran Bingham a écrit : > > On 05/02/2020 14:03, Nicolas Dufresne wrote: > >> Le mer. 5 févr. 2020 08 h 04, Kieran Bingham a écrit : > >>> > >>> When developing and testing libcamera, the usual development model is to > >>> compile and run one of the test or utility applications. > >> > >> I like it. Be aware that it won't work for me. It only work if the build > >> path matches run path, which isn't the case when cross compiling and > >> exporting over NFS. Any suggestion ? > > > > Interesting (and painful) point. > > > > Ideally it would be a relative path, but the binary path > > (/proc/self/exe) doesn't always have to stay relative to the library > > path ... > > > > I wonder if I can get the library path at runtime... Time to dig into > > what else is in the _DYNAMIC table perhaps. > > > > Otherwise, I'm certainly open to suggestions from the list here ;-) > > Note that meanwhile I can just set the env really, I'm a bit use to that anyway. > GStreamer, GLib and Mesa (which are the kind of stuff I cross compile) all > requires few envs already. How about installing libcamera instead of copying binaries ? :-) You can set the prefix to the path on your target system, and install to your NFS directory by setting the DESTDIR variable for meson install. > >>> IPA modules are loaded by the IPAManager, from a system path, or by > >>> parsing an environment variable. > >>> > >>> Provide the build path to the library through a temporary storage in the > >>> runpath of the ELF library strings table. This entry is stripped at > >>> install time, but allows us to identify the location of the recently > >>> compiled IPA modules without the user having to manually declare paths to the > >>> build system. > >>> > >>> Previously to this series the IPA tests would only be able to be run > >>> from the root of the build tree, due to the hardcoded path relative to that > >>> point. Now that the IPAs can be found from their build location, we no longer > >>> need to provide this hardcoded path through the LIBCAMERA_IPA_MODULE_PATH > >>> for tests, and as a further consequence they can be run directly without > >>> requiring the launch to be run from the top level of the build tree. > >>> > >>> Kieran Bingham (5): > >>> libcamera: utils: Provide helper to get dynamic library runpath > >>> libcamera: ipa_manager: Split path handling > >>> libcamera: ipa_manager: Allow recursive parsing > >>> libcamera: ipa_manager: Search the runpath for IPA libraries > >>> tests: Remove IPA_MODULE_PATH environment variable > >>> > >>> src/libcamera/include/ipa_manager.h | 5 +- > >>> src/libcamera/include/utils.h | 1 + > >>> src/libcamera/ipa_manager.cpp | 111 ++++++++++++++++++++++------ > >>> src/libcamera/meson.build | 1 + > >>> src/libcamera/utils.cpp | 26 +++++++ > >>> src/meson.build | 7 ++ > >>> test/libtest/test.cpp | 4 - > >>> 7 files changed, 126 insertions(+), 29 deletions(-)
Le jeudi 06 février 2020 à 22:39 +0200, Laurent Pinchart a écrit : > Hi Nicolas, > > On Wed, Feb 05, 2020 at 01:49:11PM -0500, Nicolas Dufresne wrote: > > Le mercredi 05 février 2020 à 14:12 +0000, Kieran Bingham a écrit : > > > On 05/02/2020 14:03, Nicolas Dufresne wrote: > > > > Le mer. 5 févr. 2020 08 h 04, Kieran Bingham a écrit : > > > > > When developing and testing libcamera, the usual development model is to > > > > > compile and run one of the test or utility applications. > > > > > > > > I like it. Be aware that it won't work for me. It only work if the build > > > > path matches run path, which isn't the case when cross compiling and > > > > exporting over NFS. Any suggestion ? > > > > > > Interesting (and painful) point. > > > > > > Ideally it would be a relative path, but the binary path > > > (/proc/self/exe) doesn't always have to stay relative to the library > > > path ... > > > > > > I wonder if I can get the library path at runtime... Time to dig into > > > what else is in the _DYNAMIC table perhaps. > > > > > > Otherwise, I'm certainly open to suggestions from the list here ;-) > > > > Note that meanwhile I can just set the env really, I'm a bit use to that anyway. > > GStreamer, GLib and Mesa (which are the kind of stuff I cross compile) all > > requires few envs already. > > How about installing libcamera instead of copying binaries ? :-) You can > set the prefix to the path on your target system, and install to your > NFS directory by setting the DESTDIR variable for meson install. I'm not sure what you refer to with "installing instead of copying binaries" (that sounds like the same thing, as installing requires copying binaries). I'm strictly speaking about running things from build tree here, something we happen to have been doing for more then a decade in the GStreamer project. We use environments though, as your solution isn't portable, we just don't have that luxury to ignore other OS. > > > > > > IPA modules are loaded by the IPAManager, from a system path, or by > > > > > parsing an environment variable. > > > > > > > > > > Provide the build path to the library through a temporary storage in the > > > > > runpath of the ELF library strings table. This entry is stripped at > > > > > install time, but allows us to identify the location of the recently > > > > > compiled IPA modules without the user having to manually declare paths to the > > > > > build system. > > > > > > > > > > Previously to this series the IPA tests would only be able to be run > > > > > from the root of the build tree, due to the hardcoded path relative to that > > > > > point. Now that the IPAs can be found from their build location, we no longer > > > > > need to provide this hardcoded path through the LIBCAMERA_IPA_MODULE_PATH > > > > > for tests, and as a further consequence they can be run directly without > > > > > requiring the launch to be run from the top level of the build tree. > > > > > > > > > > Kieran Bingham (5): > > > > > libcamera: utils: Provide helper to get dynamic library runpath > > > > > libcamera: ipa_manager: Split path handling > > > > > libcamera: ipa_manager: Allow recursive parsing > > > > > libcamera: ipa_manager: Search the runpath for IPA libraries > > > > > tests: Remove IPA_MODULE_PATH environment variable > > > > > > > > > > src/libcamera/include/ipa_manager.h | 5 +- > > > > > src/libcamera/include/utils.h | 1 + > > > > > src/libcamera/ipa_manager.cpp | 111 ++++++++++++++++++++++------ > > > > > src/libcamera/meson.build | 1 + > > > > > src/libcamera/utils.cpp | 26 +++++++ > > > > > src/meson.build | 7 ++ > > > > > test/libtest/test.cpp | 4 - > > > > > 7 files changed, 126 insertions(+), 29 deletions(-)
Hi Nicolas, On Sat, Feb 08, 2020 at 12:54:52PM -0500, Nicolas Dufresne wrote: > Le jeudi 06 février 2020 à 22:39 +0200, Laurent Pinchart a écrit : > > On Wed, Feb 05, 2020 at 01:49:11PM -0500, Nicolas Dufresne wrote: > >> Le mercredi 05 février 2020 à 14:12 +0000, Kieran Bingham a écrit : > >>> On 05/02/2020 14:03, Nicolas Dufresne wrote: > >>>> Le mer. 5 févr. 2020 08 h 04, Kieran Bingham a écrit : > >>>>> When developing and testing libcamera, the usual development model is to > >>>>> compile and run one of the test or utility applications. > >>>> > >>>> I like it. Be aware that it won't work for me. It only work if the build > >>>> path matches run path, which isn't the case when cross compiling and > >>>> exporting over NFS. Any suggestion ? > >>> > >>> Interesting (and painful) point. > >>> > >>> Ideally it would be a relative path, but the binary path > >>> (/proc/self/exe) doesn't always have to stay relative to the library > >>> path ... > >>> > >>> I wonder if I can get the library path at runtime... Time to dig into > >>> what else is in the _DYNAMIC table perhaps. > >>> > >>> Otherwise, I'm certainly open to suggestions from the list here ;-) > >> > >> Note that meanwhile I can just set the env really, I'm a bit use to that anyway. > >> GStreamer, GLib and Mesa (which are the kind of stuff I cross compile) all > >> requires few envs already. > > > > How about installing libcamera instead of copying binaries ? :-) You can > > set the prefix to the path on your target system, and install to your > > NFS directory by setting the DESTDIR variable for meson install. > > I'm not sure what you refer to with "installing instead of copying > binaries" (that sounds like the same thing, as installing requires > copying binaries). I'm strictly speaking about running things from > build tree here, something we happen to have been doing for more then a > decade in the GStreamer project. We use environments though, as your > solution isn't portable, we just don't have that luxury to ignore other > OS. Yes, if you run directly from the build tree, it's an issue not solved by this series. But wouldn't it be better in that case to install to the NFS root as part of the (cross-)compilation on the host instead of running in the build tree ? > >>>>> IPA modules are loaded by the IPAManager, from a system path, or by > >>>>> parsing an environment variable. > >>>>> > >>>>> Provide the build path to the library through a temporary storage in the > >>>>> runpath of the ELF library strings table. This entry is stripped at > >>>>> install time, but allows us to identify the location of the recently > >>>>> compiled IPA modules without the user having to manually declare paths to the > >>>>> build system. > >>>>> > >>>>> Previously to this series the IPA tests would only be able to be run > >>>>> from the root of the build tree, due to the hardcoded path relative to that > >>>>> point. Now that the IPAs can be found from their build location, we no longer > >>>>> need to provide this hardcoded path through the LIBCAMERA_IPA_MODULE_PATH > >>>>> for tests, and as a further consequence they can be run directly without > >>>>> requiring the launch to be run from the top level of the build tree. > >>>>> > >>>>> Kieran Bingham (5): > >>>>> libcamera: utils: Provide helper to get dynamic library runpath > >>>>> libcamera: ipa_manager: Split path handling > >>>>> libcamera: ipa_manager: Allow recursive parsing > >>>>> libcamera: ipa_manager: Search the runpath for IPA libraries > >>>>> tests: Remove IPA_MODULE_PATH environment variable > >>>>> > >>>>> src/libcamera/include/ipa_manager.h | 5 +- > >>>>> src/libcamera/include/utils.h | 1 + > >>>>> src/libcamera/ipa_manager.cpp | 111 ++++++++++++++++++++++------ > >>>>> src/libcamera/meson.build | 1 + > >>>>> src/libcamera/utils.cpp | 26 +++++++ > >>>>> src/meson.build | 7 ++ > >>>>> test/libtest/test.cpp | 4 - > >>>>> 7 files changed, 126 insertions(+), 29 deletions(-)
Le mardi 11 février 2020 à 17:51 +0200, Laurent Pinchart a écrit : > Hi Nicolas, > > On Sat, Feb 08, 2020 at 12:54:52PM -0500, Nicolas Dufresne wrote: > > Le jeudi 06 février 2020 à 22:39 +0200, Laurent Pinchart a écrit : > > > On Wed, Feb 05, 2020 at 01:49:11PM -0500, Nicolas Dufresne wrote: > > > > Le mercredi 05 février 2020 à 14:12 +0000, Kieran Bingham a écrit : > > > > > On 05/02/2020 14:03, Nicolas Dufresne wrote: > > > > > > Le mer. 5 févr. 2020 08 h 04, Kieran Bingham a écrit : > > > > > > > When developing and testing libcamera, the usual development model is to > > > > > > > compile and run one of the test or utility applications. > > > > > > > > > > > > I like it. Be aware that it won't work for me. It only work if the build > > > > > > path matches run path, which isn't the case when cross compiling and > > > > > > exporting over NFS. Any suggestion ? > > > > > > > > > > Interesting (and painful) point. > > > > > > > > > > Ideally it would be a relative path, but the binary path > > > > > (/proc/self/exe) doesn't always have to stay relative to the library > > > > > path ... > > > > > > > > > > I wonder if I can get the library path at runtime... Time to dig into > > > > > what else is in the _DYNAMIC table perhaps. > > > > > > > > > > Otherwise, I'm certainly open to suggestions from the list here ;-) > > > > > > > > Note that meanwhile I can just set the env really, I'm a bit use to that anyway. > > > > GStreamer, GLib and Mesa (which are the kind of stuff I cross compile) all > > > > requires few envs already. > > > > > > How about installing libcamera instead of copying binaries ? :-) You can > > > set the prefix to the path on your target system, and install to your > > > NFS directory by setting the DESTDIR variable for meson install. > > > > I'm not sure what you refer to with "installing instead of copying > > binaries" (that sounds like the same thing, as installing requires > > copying binaries). I'm strictly speaking about running things from > > build tree here, something we happen to have been doing for more then a > > decade in the GStreamer project. We use environments though, as your > > solution isn't portable, we just don't have that luxury to ignore other > > OS. > > Yes, if you run directly from the build tree, it's an issue not solved > by this series. But wouldn't it be better in that case to install to the > NFS root as part of the (cross-)compilation on the host instead of > running in the build tree ? In my setup, the build tree is exported over NFS. So on the nfs server, which is the build server too, I do: cd /path/to/nfs/something/gst-build ninja -C build And on the target: cd something/gst-build ./gst-unisntalled.py --sysroot /path/to/nfs I've aggregated libcamera to gst-build (it's extensible), but still need some env specific to libcamera. I tried this patchset, but still needed the env. Now my setup have no secret anymore ;-D That in no way invalidate this patch, I think it's really nice for those testing on host (should work with virtme too). > > > > > > > > IPA modules are loaded by the IPAManager, from a system path, or by > > > > > > > parsing an environment variable. > > > > > > > > > > > > > > Provide the build path to the library through a temporary storage in the > > > > > > > runpath of the ELF library strings table. This entry is stripped at > > > > > > > install time, but allows us to identify the location of the recently > > > > > > > compiled IPA modules without the user having to manually declare paths to the > > > > > > > build system. > > > > > > > > > > > > > > Previously to this series the IPA tests would only be able to be run > > > > > > > from the root of the build tree, due to the hardcoded path relative to that > > > > > > > point. Now that the IPAs can be found from their build location, we no longer > > > > > > > need to provide this hardcoded path through the LIBCAMERA_IPA_MODULE_PATH > > > > > > > for tests, and as a further consequence they can be run directly without > > > > > > > requiring the launch to be run from the top level of the build tree. > > > > > > > > > > > > > > Kieran Bingham (5): > > > > > > > libcamera: utils: Provide helper to get dynamic library runpath > > > > > > > libcamera: ipa_manager: Split path handling > > > > > > > libcamera: ipa_manager: Allow recursive parsing > > > > > > > libcamera: ipa_manager: Search the runpath for IPA libraries > > > > > > > tests: Remove IPA_MODULE_PATH environment variable > > > > > > > > > > > > > > src/libcamera/include/ipa_manager.h | 5 +- > > > > > > > src/libcamera/include/utils.h | 1 + > > > > > > > src/libcamera/ipa_manager.cpp | 111 ++++++++++++++++++++++------ > > > > > > > src/libcamera/meson.build | 1 + > > > > > > > src/libcamera/utils.cpp | 26 +++++++ > > > > > > > src/meson.build | 7 ++ > > > > > > > test/libtest/test.cpp | 4 - > > > > > > > 7 files changed, 126 insertions(+), 29 deletions(-)