[CMake] Interface Libraries allow include directories but not link directories.. Why?

Thu Aug 24 13:26:57 EDT 2017

On Thu, Aug 24, 2017 at 2:46 AM, Jean-Michaël Celerier <
jeanmichael.celerier at gmail.com> wrote:

>
> Ok got it sorry to hear that certainly because, as soon as I hear
>> something that would be useful somehow I end up needing it the next day.
>> So sorry for us both.
>>
>> From what your are saying (and I will take your word for it) the CMake
>> has a another problem in not implementing "inherited build properties"
>> correctly.  That is of course if that is what CMake is after with
>> add_library( targ INTERFACE) in the first place.
>>
>>
> I think that there is just no mechanism for "inherited build properties".
> From the docs (https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.
> 7.html#interface-libraries), INTERFACE targets seems to be meant for
> header-only libraries.
>
> The "inheritance" mechanism in CMake is mainly setting variables in a
> given folder, but this is imho not flexible enough, and leads to problems
> when you want to use your library as a subfolder of another since you don't
> have an easy way to overwrite "child" variables from a parent scope unless
> the child scope carefully did set(CMAKE_CXX_FLAGS "-my-flags
> ${CMAKE_CXX_FLAGS}") every time.
>
>

Yes absolutely the inheritance mech is folder based and is the very
problem.  This is the very problem with LINK_DIRECTORIES,
INCLUDE_DIRECTORIES, and flags I initial had in 2009 and from from the
current state of things 8 years later it appears that not much is changed.
I have been able to use the interface mech to get around what was my
use-case for my "project/config" macros, but from what your saying I will
only get so far before the CMake design rope around my ankle staked out at
the start line ends in me falling flat on my face.

It is refreshing to see there is at least someone else out there that
understands this core problem in CMake, wish Kitware did, Boost.Build
had/has no such problem.  We as humans learn form our mistakes... over and
over again... every generation... sadly they are the same mistakes.  You
state IMHO, but there are no opinions involved on my end... it is simply a
FACT that CMake design is flawed.  Personally I am way past opinions.  It
appears that I must begin Honey Badgering ;-) the devs until this is
finally fixed or just fix it myself.

If you have some CMake code that you now does now work say in a test proj I
can test to see what fully does not work then I can add this to my issues
when I begin the feature request / request for sanity.

Also I will likely post another inherited build props specific post so that
these problems and be discussed specifically and can be refereed to by devs
for the why.

I don't know if you have a current macro end-around solution, but if you
want I could post my project/config macros on git hub.  You would likely
have to mod those to get add_project_configuration  to accept all your
build props to be inherited.  Ideally I long for a core solution in CMake
and thought / hoped I had it with interface.  Thanks for crushing my hopes
and  dreams :-).

At one time I did have a compiler_config in my code so your needs for CXX
Flags may just work with below (it's commented out in my current proj, but
the place holder is still there)

add_project_configuration(
    compiler_config
#    CXX_FLAGS_INIT
#        "/DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR "
#    CXX_FLAGS_DEBUG
#        "/D_DEBUG ${THREAD_DEBUG_OPT} /Zi /Ob0 /Od /Gm "
#    CXX_FLAGS_DEBUG_INIT
#        "/D_DEBUG ${THREAD_DEBUG_OPT} /Zi /Ob0 /Od "
#
#    C_FLAGS_DEBUG
#        "/D_DEBUG /MDd  /Zi  /Ob0 /Od  "
#    C_FLAGS_DEBUG_INIT
#        "/D_DEBUG /MDd /Zi  /Ob0 /Od "
#
#    CXX_FLAGS_MINSIZEREL_INIT
#        "/MD /O1 /Ob1 /D NDEBUG"
#    CXX_FLAGS_RELEASE_INIT
#        "/MD /O2 /Ob2 /D NDEBUG"
#    CXX_FLAGS_RELWITHDEBINFO_INIT
#        "/MD /Zi /O2 /Ob1 /D NDEBUG"
#
#    C_FLAGS_INIT
#        "/DWIN32 /D_WINDOWS /W3 /Zm1000"
#    C_FLAGS_MINSIZEREL_INIT
#        "/MD /O1 /Ob1 /D NDEBUG"
#    C_FLAGS_RELEASE_INIT
#        "/MD /O2 /Ob2 /D NDEBUG"
#    C_FLAGS_RELWITHDEBINFO_INIT
#        "/MD /Zi /O2 /Ob1 /D NDEBUG"
#    # the following line should break the build when it is working!! Right
now it is not as all FLAGS are not working.
#    C_STANDARD_LIBRARIES_INIT
#        "kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib
ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib mylib.lib"
#    COMPILE_FLAGS /DGOOP_123
    LINKER_LANGUAGE
        CXX
)

Then the config props can be inherited as:

add_project_library(
    GP_Loader
    INHERIT_CONFIGURATIONS
        compiler_config
        mex_config
        utility_config
        boost_config
    CPP_SOURCES
        GP_Loader.cpp
        ${GP_LINK}
    INSTALL_DIRECTORIES
#        ${CMAKE_CURRENT_SOURCE_DIR}
        bin
        ${TOP}/source/Matlab/lib
    LIB_SUFFIX
        ${MEX_LIB_EXT}
)

Certainly much less verbose that vanilla CMake goop.  If interested let me
know, but like I said may require some work to get them to do what you need
as I only exposed enough CMake to get what I needed and do not handle every
CMake command.  I refer to it as Super Awesome Projects (SAP), but like
anything created in a vacuum I am certain once the seal it cracked and
exposed to the community it sucks to some degree or another. I just could
not come up with a working acronym for SUCKER ;-)

Why oh why cruel world is this the state of things?  Sigh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170824/9da99a80/attachment.html>