src/CMakeLists.txt: do not force the build of a shared library
diff mbox series

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
Related show

Commit Message

'Chmielewski Andreas' via swupdate May 22, 2019, 4:10 p.m. UTC
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(-)

Comments

Stefano Babic May 31, 2019, 11:10 a.m. UTC | #1
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)
>
'Chmielewski Andreas' via swupdate May 31, 2019, 9:14 p.m. UTC | #2
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
Stefano Babic June 1, 2019, 8:54 a.m. UTC | #3
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.

Patch
diff mbox series

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)