| Message ID | 1558541416-5770-1-git-send-email-pjtexier@koncepto.io |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | src/CMakeLists.txt: do not force the build of a shared library | expand |
Hi Pierre-Jean, On 22/05/19 18:10, 'Pierre-Jean Texier' via swupdate wrote: > By definition, projects using CMake which can build either static or shared > libraries use a BUILD_SHARED_LIBS flag to allow selecting between both. > So, let CMake rely on the standard BUILD_SHARED_LIBS variable to decide > whether a static or shared library should be built. > Current recipe builds both shared and static library. A .bbappend could then decide what it wants. Instead of this, should we not simply add a libubootenv-static package ? > however, we can control the behaviour as follows: > > $. cmake -DBUILD_SHARED_LIBS=OFF ... > > $. cmake -DBUILS_SHARED_LIBS=ON ... > > With Yocto/OE, just add the following option into the libubootenv recipe : > > EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON" > Does this constrain anyone to add a .bbappend ? Best regards, Stefano Babic > Signed-off-by: Pierre-Jean Texier <pjtexier@koncepto.io> > --- > src/CMakeLists.txt | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt > index 051732b..c5f6dcb 100644 > --- a/src/CMakeLists.txt > +++ b/src/CMakeLists.txt > @@ -10,10 +10,9 @@ SET(include_HEADERS > libuboot.h > ) > > -add_library(ubootenv SHARED ${libubootenv_SOURCES} ${include_HEADERS}) > +add_library(ubootenv ${libubootenv_SOURCES} ${include_HEADERS}) > SET_TARGET_PROPERTIES(ubootenv PROPERTIES SOVERSION ${SOVERSION}) > > -ADD_LIBRARY(ubootenv_static STATIC ${libubootenv_SOURCES} ${include_HEADERS}) > add_executable(fw_printenv fw_printenv.c) > add_executable(fw_setenv fw_setenv.c) > target_link_libraries(fw_printenv ubootenv z) >
Hi Stefano, Le 31/05/2019 à 13:10, Stefano Babic a écrit : > Current recipe builds both shared and static library. A .bbappend could > then decide what it wants. Instead of this, should we not simply add a > libubootenv-static package ? In fact, I made this patch for libubootenv when I had to use a "full static toolchain" (br-arm-full-static), means without dynamic library support. This is a test provided by Buildroot when integrating a new package (wih test-pkg). For example, you can check the failure with the initial CMakeList.txt [1]. So I thought it would be better to use the CMake mechanism (BUILD_SHARED_LIBS) to not build both libraries. >> however, we can control the behaviour as follows: >> >> $. cmake -DBUILD_SHARED_LIBS=OFF ... >> >> $. cmake -DBUILS_SHARED_LIBS=ON ... >> >> With Yocto/OE, just add the following option into the libubootenv recipe : >> >> EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON" >> > Does this constrain anyone to add a .bbappend ? As is, yes you are right, but maybe people using libubootenv (with Yocto/OE for sure) already have a .bbappend (to install fw_env.config for instance) ? So, maybe it would be interesting to set a default value for the Yocto/OE recipe ? (shared lib ?), or do you prefer to keep the current implementation in libubootenv ? Thanks, [1] - http://autobuild.buildroot.net/results/e1837ccbe774071876642655b1fcffbd69dd7947/build-end.log
Hi Pierre-Jean, On 31/05/19 23:14, 'Pierre-Jean Texier' via swupdate wrote: > Hi Stefano, > > Le 31/05/2019 à 13:10, Stefano Babic a écrit : >> Current recipe builds both shared and static library. A .bbappend could >> then decide what it wants. Instead of this, should we not simply add a >> libubootenv-static package ? > > In fact, I made this patch for libubootenv when I had to use a > "full static toolchain" (br-arm-full-static), means without dynamic > library support. > This is a test provided by Buildroot when integrating a new package (wih > test-pkg). > > For example, you can check the failure with the initial CMakeList.txt [1]. > So I thought it would be better to use the CMake > mechanism (BUILD_SHARED_LIBS) to not build both libraries. > >>> however, we can control the behaviour as follows: >>> >>> $. cmake -DBUILD_SHARED_LIBS=OFF ... >>> >>> $. cmake -DBUILS_SHARED_LIBS=ON ... >>> >>> With Yocto/OE, just add the following option into the libubootenv recipe : >>> >>> EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON" >>> >> Does this constrain anyone to add a .bbappend ? > As is, yes you are right, but maybe people using libubootenv (with > Yocto/OE for sure) > already have a .bbappend (to install fw_env.config for instance) ? > > So, maybe it would be interesting to set a default value for the > Yocto/OE recipe ? (shared lib ?), Yes, at least a default is needed. > or do you prefer to keep the current implementation in libubootenv ? > In OE it is quite common to have both shared and static libraries, and static libraries sould be packaged into a ${PN}-staticdev. At least for OE, I would like to get the static package in case of static linking (mainly to the applicaton) - currently is not built. To solve your use case, I would like to see that both libraries are built as default, but it could be possible to override this via cmake instead of just choosing one of the two types. Best regards, Stefano > Thanks, > > [1] - > http://autobuild.buildroot.net/results/e1837ccbe774071876642655b1fcffbd69dd7947/build-end.log > > -- > Best regards, > Pierre-Jean Texier > > -- > You received this message because you are subscribed to the Google > Groups "swupdate" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to swupdate+unsubscribe@googlegroups.com > <mailto:swupdate+unsubscribe@googlegroups.com>. > To post to this group, send email to swupdate@googlegroups.com > <mailto:swupdate@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/swupdate/a83e0724-856f-2286-c7b6-cd8c3335c224%40koncepto.io > <https://groups.google.com/d/msgid/swupdate/a83e0724-856f-2286-c7b6-cd8c3335c224%40koncepto.io?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout.
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt index 051732b..c5f6dcb 100644 --- a/src/CMakeLists.txt +++ b/src/CMakeLists.txt @@ -10,10 +10,9 @@ SET(include_HEADERS libuboot.h ) -add_library(ubootenv SHARED ${libubootenv_SOURCES} ${include_HEADERS}) +add_library(ubootenv ${libubootenv_SOURCES} ${include_HEADERS}) SET_TARGET_PROPERTIES(ubootenv PROPERTIES SOVERSION ${SOVERSION}) -ADD_LIBRARY(ubootenv_static STATIC ${libubootenv_SOURCES} ${include_HEADERS}) add_executable(fw_printenv fw_printenv.c) add_executable(fw_setenv fw_setenv.c) target_link_libraries(fw_printenv ubootenv z)
By definition, projects using CMake which can build either static or shared libraries use a BUILD_SHARED_LIBS flag to allow selecting between both. So, let CMake rely on the standard BUILD_SHARED_LIBS variable to decide whether a static or shared library should be built. however, we can control the behaviour as follows: $. cmake -DBUILD_SHARED_LIBS=OFF ... $. cmake -DBUILS_SHARED_LIBS=ON ... With Yocto/OE, just add the following option into the libubootenv recipe : EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON" Signed-off-by: Pierre-Jean Texier <pjtexier@koncepto.io> --- src/CMakeLists.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)