Separate FLTK cmake files for shared and static libraries.

114 views
Skip to first unread message

Richard Shaw

unread,
Oct 20, 2014, 10:02:22 AM10/20/14
to fltkg...@googlegroups.com
I'm not sure how much trouble this would be and I could be asking a lot but it would be very nice to have separate cmake library import files for shared and static libs. 

The reason for this request is that it's very common to package static libraries separate from shared libraries. Unfortunately if the end user only installs the static libraries, when you run "find_package(...)" to setup FLTK cmake will error out because the static libraries are not physically present. 

If the files were separated then they could be packaged separately and it solves the problem.

Thanks,
Richard

Michael Surette

unread,
Oct 20, 2014, 12:25:34 PM10/20/14
to fltkg...@googlegroups.com

In the current svn and therefore in the next release the static and dynamic libraries have different CMake names, which is a solution to this problem.
After having looked at your posted patches, I think that those problems may have been fixed as well. I'll need the time to look closer to be sure.

Richard Shaw

unread,
Oct 20, 2014, 3:53:39 PM10/20/14
to fltkg...@googlegroups.com
On Mon, Oct 20, 2014 at 11:25 AM, Michael Surette <mjsu...@gmail.com> wrote:

In the current svn and therefore in the next release the static and dynamic libraries have different CMake names, which is a solution to this problem.
After having looked at your posted patches, I think that those problems may have been fixed as well. I'll need the time to look closer to be sure.


It looks like that's mostly true, the install is now in a function in macros.cmake but the destinations are hard coded:

    install(TARGETS ${LIBRARY_NAME}
        EXPORT FLTK-Targets
        RUNTIME DESTINATION bin
        LIBRARY DESTINATION lib
        ARCHIVE DESTINATION lib
        )

Here's where the GNUInstallDirs module would be nice. After including it you could change it to:

    install(TARGETS ${LIBRARY_NAME}
        EXPORT FLTK-Targets
        RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
        LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
        ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
        )
 
Then those locations could be easily overridden by the end user if needed.

Thanks,
Richard

Michael Surette

unread,
Oct 21, 2014, 6:44:22 AM10/21/14
to fltkg...@googlegroups.com
On Mon, Oct 20, 2014 at 3:53 PM, Richard Shaw wrote:
> On Mon, Oct 20, 2014 at 11:25 AM, Michael Surette
> --
> You received this message because you are subscribed to the Google Groups
> "fltk.general" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fltkgeneral...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Thank you for the clarification. I can see where this would be useful.

Unfortunately GNUInstallDirs is a CMake v3 feature. For
cross-platform compatibility reasons, bumping the minimum required
version of CMake is a concern.

I'll see what I can work out when I put my nose back to the grindstone.

--
Mike

Richard Shaw

unread,
Oct 21, 2014, 8:56:53 AM10/21/14
to fltkg...@googlegroups.com
On Tue, Oct 21, 2014 at 5:44 AM, Michael Surette wrote:
Unfortunately GNUInstallDirs is a CMake v3 feature.  For
cross-platform compatibility reasons, bumping the minimum required
version of CMake is a concern.

I'm not exactly sure when it was added but it's definitely in 2.8.12.  

Thanks,
Richard

MacArthur, Ian (Selex ES, UK)

unread,
Oct 21, 2014, 9:08:41 AM10/21/14
to fltkg...@googlegroups.com

On Tue, Oct 21, 2014 at 5:44 AM, Michael Surette wrote:

Unfortunately GNUInstallDirs is a CMake v3 feature.  For
cross-platform compatibility reasons, bumping the minimum required
version of CMake is a concern.

 

I'm not exactly sure when it was added but it's definitely in 2.8.12.  

 

 

FWIW (and I know nothing useful to add about cmake) I appear to have GNUInstallDirs.cmake in the Modules folder on my cmake 2.8.10.2, and there is essentially zero chance I installed that myself later, so presumably it was part of the tarball I built...

 

 

Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales.  Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

Michael Surette

unread,
Oct 21, 2014, 9:01:37 PM10/21/14
to fltkg...@googlegroups.com
On Tue, Oct 21, 2014 at 9:08 AM, MacArthur, Ian (Selex ES, UK) wrote:
> On Tue, Oct 21, 2014 at 5:44 AM, Michael Surette wrote:
>
> Unfortunately GNUInstallDirs is a CMake v3 feature. For
> cross-platform compatibility reasons, bumping the minimum required
> version of CMake is a concern.
>
>
>
> I'm not exactly sure when it was added but it's definitely in 2.8.12.
>
>
>
>
>
> FWIW (and I know nothing useful to add about cmake) I appear to have
> GNUInstallDirs.cmake in the Modules folder on my cmake 2.8.10.2, and there
> is essentially zero chance I installed that myself later, so presumably it
> was part of the tarball I built...
>
I googled GNUInstallDirs.cmake and the CMake v3 documentation showed
up so I jumped to a wrong conclusion. I wish there was a list of
which CMake modules and what versions they're in.

CMake 2.8 is now very widely carried by Linux distros. I assume that
anyone else who wants to run CMake would have to install it
themselves, so they may as well get the latest. That would make 2.8
and GNUInstallDirs a viable step up.

--
Mike

Albrecht Schlosser

unread,
Oct 22, 2014, 5:56:03 AM10/22/14
to fltkg...@googlegroups.com
On 22.10.2014 at 03:01 Michael Surette wrote:

> I googled GNUInstallDirs.cmake and the CMake v3 documentation showed
> up so I jumped to a wrong conclusion. I wish there was a list of
> which CMake modules and what versions they're in.

There is one (I googled "CMake releases"):

http://www.cmake.org/Wiki/CMake_Released_Versions

leads to <http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix>

and in
<http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix/StandardCMakeModulesFindL>

you can see that GNUInstallDirs appeared in 2.8.5 which was released on
08 Jul 2011 according to the first link.

> CMake 2.8 is now very widely carried by Linux distros. I assume that
> anyone else who wants to run CMake would have to install it
> themselves, so they may as well get the latest. That would make 2.8
> and GNUInstallDirs a viable step up.

Currently we have minimum 2.6, and 2.6.0 was release on 07 May 2008, so
this was about three years earlier.

OTOH, 2.8.5 is now more than three years old, and we could probably
think about using 2.8.5 as the minimum required CMake version. At least
if GNUInstallDirs usage was more than just "convenient".

One of FLTK's major compatibility concerns is embedded platforms with
old build chains. However, I believe that these would mostly be
cross-compiled, and hence they could probably use a more recent build
host (or could currently keep using autotools).

Comments, anybody?

Richard Shaw

unread,
Oct 22, 2014, 8:53:54 AM10/22/14
to fltkg...@googlegroups.com
On Wed, Oct 22, 2014 at 4:56 AM, Albrecht Schlosser wrote:
One of FLTK's major compatibility concerns is embedded platforms with old build chains. However, I believe that these would mostly be cross-compiled, and hence they could probably use a more recent build host (or could currently keep using autotools).

Comments, anybody?

There are a couple of alternatives, not that I think they are necessarily GOOD alternatives, but I thought they were worth mentioning:

1. Copy the GNUInstallDirs into FLTK and do a test for cmake version, if it's 2.8.5 or higher, use the system module, if less than 2.8.5, use the bundled module.
2. Test for the version and if it's too low, assign some default (cache) values to the same variable names, otherwise include the system module.

Thanks,
Richard

Michael Surette

unread,
Oct 23, 2014, 5:11:14 PM10/23/14
to fltkg...@googlegroups.com
I'll have to see what I can be done without GNUInstallDirs. After all,
all we're looking for is sensible default install dirs that can be
overridden.
> --
> You received this message because you are subscribed to the Google Groups
> "fltk.general" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fltkgeneral...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Mike

Richard Shaw

unread,
Oct 24, 2014, 9:25:25 AM10/24/14
to fltkg...@googlegroups.com
On Thu, Oct 23, 2014 at 4:11 PM, Michael Surette <mjsu...@gmail.com> wrote:
I'll have to see what I can be done without GNUInstallDirs. After all,
all we're looking for is sensible default install dirs that can be
overridden.

The nice thing about GNUInstallDirs is that it has platform specific install locations including dealing with lib or lib64 for multilib linux systems, by the time you implement everything yourself, you might as well use it :) Also, it has an absolute directory option CMAKE_INSTALL_FULL_<dir> which can be convenient. 

Thanks,
Richard 
Reply all
Reply to author
Forward
0 new messages