On Fri, 10 Mar 2023 at 13:10, zyx <z...@gmx.us> wrote: > What I'm questioning is the variable name, the PODOFO_STATIC. Why would > not keep the PODOFO_BUILD_STATIC name for it? Is there any advantage > with it?
The reason was to leave PODOFO_BUILD_STATIC and PODOFO_BUILD_SHARED free for potential future use case when we want to forcefully build both the static and shared targets (this is not supported today). If you are unconvinced with the current naming, try to immagine these variables by their semantical meaning: 1) Boolean to decide if building the default library target as static (TRUE) or shared (FALSE) and use it for tests/tools/examples. Today name: PODOFO_STATIC; 2) Proposed future boolean* to decide if forcefully build the static library target when set to TRUE. My proposal was to name this PODOFO_BUILD_STATIC; 3) Proposed future boolean* to decide if forcefully build the shared library target when set to TRUE. My proposal was to name this PODOFO_BUILD_SHARED. Another possible naming that would more backward compatible could be: 1) PODOFO_BUILD_STATIC; 2) PODOFO_ENABLE_STATIC_TARGET; 3) PODOFO_ENABLE_SHARED_TARGET. Even with this naming I would still drop support for PODOFO_BUILD_SHARED: please, one decision -> one variable, not two with complementary meaning. Let me know what you think about and/or add your proposal. (*) To be added later, maybe. On Fri, 10 Mar 2023 at 14:02, Raul Metsma <r...@metsma.ee> wrote: > There is built in variable in cmake > BUILD_SHARED_LIBS — CMake 3.26.0-rc6 Documentation > cmake.org > I was aware of this variable, and I tried using it but the issue is that it doesn't grasp the fact that when unset or FALSE I would like the default to be shared. So I ended preferring a variable that when affirmatively set to TRUE it changes the default behavior, and avoiding the use of BUILD_SHARED_LIBS. _______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
