On Wed, Sep 3, 2014 at 9:11 AM, Brad King <[email protected]> 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
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
