[cmake-developers] Best practice for determining if a static library was found and other issues with FindFLTK.cmake

[Richard Shaw]

On Wed, Sep 3, 2014 at 9:11 AM, Brad King <brad.king at kitware.com> wrote:

> On 09/03/2014 09:48 AM, Richard Shaw wrote:
> > The module has several issues but a major one is that it doesn't add
> > the required linker flags when using static libraries instead of shared.
> >
> > It also doesn't check for any required C flags but that's a lesser issue.
> >
> > These may only be a problem for the autotools based fltk build
> > as the module uses a ConfigFLTK for CMake based builds.
>
> If FLTK upstream is willing to provide FTLKConfig for CMake-based
> builds then they may be willing to support providing one from
> autotools-based builds too.  It is not very hard to provide one
> from a non-CMake build system.  Qt5 and LLVM both do it.  You
> could go work with the FLTK devs to do it there too.  Then we
> won't even need a FindFLTK in CMake except for compatibility.
>

I did a cmake based build for cross-compiling for win32 on Fedora because
the autotools was going to be WAY too much work to get working with the
rpmbuild mingw macros and took a look at the generated cmake files.

It looks like it uses a bunch of imported targets rather than utilizing
find_library... I'm not familiar with this method so would you just use an
"include(FLTKConfig)" instead of find_library/find_package? And then I
would add the imported targets to target_link_libraries?


> ^^^ Is this the best way to determine if the library found was
> > static or shared? ^^^
>
> It is not possible in general without platform-specific knowledge.
> On AIX even an archive (.a) can be a shared library, for example.
> On Windows a .dll's import library (.lib) looks just like a static
> library (.lib).  Ideally information provided with the FLTK package
> should tell us.
>

Hmm... no good answer here. Another reason to move away from the autotools
build... more below.

>
> > So a broader question... Should we trust the output of a config
> > program, in this case, fltk-config? The writer of the module
> > certainly doesn't. They used the fltk-config program to find
> > the base library, strip off the path portion and then used it
> > as a search path to find the libraries independently.
>
> Of course the output of fltk-config should be trusted to be
> correct, but the info still needs to be transformed into what
> CMake wants.  That is usually more granular than strings of
> command-line flags for various tools, so some parsing/searching
> may be needed.
>

Well, after a bit more research I see why he didn't trust the output of
fltk-config. I only have the shared libraries on my fedora system but if I
run "fltk-config --libs" the output shows a static library:

$ fltk-config --libs
/usr/lib64/libfltk.a


> I would like to update the module to use COMPONENTS, but the
> > current default is to find everything unless a "FLTK_SKIP_..."
> > variable is set so I assume there's a good way to keep
> > backward compatibility.
>
> The FindFLTK module was added way back in the beginning of CMake
> and has never really been modernized.  The SKIP variables may
> even predate the COMPONENTS support in find_package.
>

Ahh... Is it possible to support that now as long as if the user doesn't
specify COMPONENTS that it emulates the old behavior and tries to find
everything?

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140903/537edd5b/attachment-0002.html>