Re: [CMake] Advice on converting legacy project to modern CMake

[Robert Maynard]

> Which leads to a question I have for the Kitware types here.  What
should I suggest to my Linux enterprise distribution users? Can they
simply download and use the latest Linux binary version of CMake that
is distributed by Kitware or are there library version
incompatibilities that make that option non-viable? Alternatively, if
such users want to build modern CMake for themselves can they do that
or do system library incompatibilities stop them in that case as well?

The official CMake  binaries are built using a static libstdc++ and
static glibc so they should be able to work on any x86_64 linux
machine.

On Mon, Aug 7, 2017 at 4:53 PM, Alan W. Irwin  wrote:
> On 2017-08-07 11:35- Björn Blissing wrote:
>
>> 1. Which version if CMake should I target? I.e. Which version should
>
> I require in my cmake_minimum_required() statement?
>
> I would suggest either
>
> cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR)
>
> or
>
> cmake_minimum_required(VERSION 3.7.2 FATAL_ERROR)
>
> depending on whether the Cygwin platform (currently only making
> 3.6.2 available) is important to your users or not.
>
> Cygwin is important to PLplot so we recently adopted 3.6.2 as the
> minimum version choice as the compromise between two goals:
>
> (1) We wanted to maximize the version of policies
> (which are set by cmake_minimum_required) since the latest
> version of policies typically make a lot of sense to us
> in terms of eliminating subtle build-system bugs.
>
> (2) We wanted to minimize the minimum version to maximize the
> percentage of our users who will have that minimum version or higher
> available from the official binary CMake version that is supplied by
> their software distribution.
>
> 3.6.2 currently satisfies goal (1) reasonably well because it is not too far
> behind the latest version 3.9.0 in terms of policy.
>
> 3.6.2 also satisfies goal (2) reasonably well.  The major exception
> here is the so-called Linux "enterprise-class" distributions who go
> out of their way to **only** support old versions of Linux software
> because their customers somehow feel more comfortable with that.  For
> example, as far as I can tell from google searches, it looks like
> RedHat Linux Enterprise versions still only support CMake-2.
>
> Which leads to a question I have for the Kitware types here.  What
> should I suggest to my Linux enterprise distribution users? Can they
> simply download and use the latest Linux binary version of CMake that
> is distributed by Kitware or are there library version
> incompatibilities that make that option non-viable? Alternatively, if
> such users want to build modern CMake for themselves can they do that
> or do system library incompatibilities stop them in that case as well?
>
> If we ignore the "enterprise-class" users, then Debian stable supports
> 3.7.2.  Debian tends to be a bit of a late adopter so as far as I know
> every other non-enterprise Linux distribution and the various *BSD
> distributions supports that version of CMake or higher. And I know
> that is also true for MinGW-w64/MSYS2 and the Mac OS X distributions
> (Homebrew, MacPorts, and Fink).  So I plan to bump the minimum version
> we support to 3.7.2 as soon as Cygwin (currently only supporting
> 3.6.2) falls into line with the rest.
>
> I haven't mentioned the Windows MSVC platform here yet which is also
> important to us.  But those users are given no official choice of
> CMake as a binary download so they likely take another viable choice
> which is to download, install, and use a Kitware binary version of
> CMake for Windows, and as far as I know all released versions of
> CMake-3 (as well as CMake-2) are available that way.
>
> In any case, for whatever minimum version of CMake you adopt, you
> should test your build system for that version as well as at least the
> latest CMake version.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
>
> --
>
> 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 

Re: [CMake] Advice on converting legacy project to modern CMake

[Alan W. Irwin]

On 2017-08-07 11:35- Björn Blissing wrote:


1. Which version if CMake should I target? I.e. Which version should

I require in my cmake_minimum_required() statement?

I would suggest either

cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR)

or

cmake_minimum_required(VERSION 3.7.2 FATAL_ERROR)

depending on whether the Cygwin platform (currently only making
3.6.2 available) is important to your users or not.

Cygwin is important to PLplot so we recently adopted 3.6.2 as the
minimum version choice as the compromise between two goals:

(1) We wanted to maximize the version of policies
(which are set by cmake_minimum_required) since the latest
version of policies typically make a lot of sense to us
in terms of eliminating subtle build-system bugs.

(2) We wanted to minimize the minimum version to maximize the
percentage of our users who will have that minimum version or higher
available from the official binary CMake version that is supplied by
their software distribution.

3.6.2 currently satisfies goal (1) reasonably well because it is not too far
behind the latest version 3.9.0 in terms of policy.

3.6.2 also satisfies goal (2) reasonably well.  The major exception
here is the so-called Linux "enterprise-class" distributions who go
out of their way to **only** support old versions of Linux software
because their customers somehow feel more comfortable with that.  For
example, as far as I can tell from google searches, it looks like
RedHat Linux Enterprise versions still only support CMake-2.

Which leads to a question I have for the Kitware types here.  What
should I suggest to my Linux enterprise distribution users? Can they
simply download and use the latest Linux binary version of CMake that
is distributed by Kitware or are there library version
incompatibilities that make that option non-viable? Alternatively, if
such users want to build modern CMake for themselves can they do that
or do system library incompatibilities stop them in that case as well?

If we ignore the "enterprise-class" users, then Debian stable supports
3.7.2.  Debian tends to be a bit of a late adopter so as far as I know
every other non-enterprise Linux distribution and the various *BSD
distributions supports that version of CMake or higher. And I know
that is also true for MinGW-w64/MSYS2 and the Mac OS X distributions
(Homebrew, MacPorts, and Fink).  So I plan to bump the minimum version
we support to 3.7.2 as soon as Cygwin (currently only supporting
3.6.2) falls into line with the rest.

I haven't mentioned the Windows MSVC platform here yet which is also
important to us.  But those users are given no official choice of
CMake as a binary download so they likely take another viable choice
which is to download, install, and use a Kitware binary version of
CMake for Windows, and as far as I know all released versions of
CMake-3 (as well as CMake-2) are available that way.

In any case, for whatever minimum version of CMake you adopt, you
should test your build system for that version as well as at least the
latest CMake version.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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

Re: [CMake] Advice on converting legacy project to modern CMake

[Rolf Eike Beer]

Am 2017-08-07 11:57, schrieb Björn Blissing:

Hi Eike,


3. Some of my legacy projects have all source in the same directory,
i.e. both source and header files are in the same directory. Others
have both private and public headers in the same directory. How do I
handle this with target_include_directories()? Preferably I would 
like

to avoid reorganizing the file structure.


If things are in the same directory you don't need
target_include_directories(), as the header files will be found anyway
if you use "" (probably also <>). If they are in a different directory
it doesn't matter if the private and public things are mixed, you need
to add that directory anyway.


Lets see if I understood what you are suggesting correctly:

Alternative 1: If both source and headers are in the same directory.
===
Solution: Omit the target_include_directories() statement completely
and just add the private and public header files in the add_library()
statement and the public headers in the install(FILES ...) statement.


Alternative 2: If source and headers are separated but both private
and public headers are included in the same directory.
===
Solution: Add the private and public header files in the add_library()
statement . Then add a target_include_directories() statement such as:
target_include_directories(anvil_lib PUBLIC
$
$
)

Then add the public headers in the install(FILES ...) statement.


Yes.


Is this correct? Follow up question: Since the directory include
contains both public and private headers should the
target_include_directories() be specified as PUBLIC or PRIVATE?


I would make it public: less code, and the private headers will simply 
not exist when installed.


Eike
--

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

Re: [CMake] Advice on converting legacy project to modern CMake

[Rolf Eike Beer]

Am 2017-08-07 11:35, schrieb Björn Blissing:

Hi,

I have some legacy projects which I intend to update to modern CMake.
The documentation is good but do not really cover "best practices". So
I have some questions which I hope some of you could help to answer:

1. Which version if CMake should I target? I.e. Which version should I
require in my cmake_minimum_required() statement?


If you want to have support for compile feature (i.e. automatically 
selecting C++11 if needed), then you should use at least 3.1. I 
personally don't see a reason to start lower anyway, if someone wants to 
build your new software, getting a new CMake shouldn't a problem anyway.



3. Some of my legacy projects have all source in the same directory,
i.e. both source and header files are in the same directory. Others
have both private and public headers in the same directory. How do I
handle this with target_include_directories()? Preferably I would like
to avoid reorganizing the file structure.


If things are in the same directory you don't need 
target_include_directories(), as the header files will be found anyway 
if you use "" (probably also <>). If they are in a different directory 
it doesn't matter if the private and public things are mixed, you need 
to add that directory anyway.


Greetings,

Eike
--
--

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

[CMake] Advice on converting legacy project to modern CMake

[Björn Blissing]

Hi,

I have some legacy projects which I intend to update to modern CMake. The 
documentation is good but do not really cover "best practices". So I have some 
questions which I hope some of you could help to answer:

1. Which version if CMake should I target? I.e. Which version should I require 
in my cmake_minimum_required() statement?

2. What are some best practices when choosing a namespace for my library 
export? For example, lets say that I have a library which handles interfacing 
with a piece of fictional hardware, lets call this hardware "Anvil". My library 
and project is then aptly named "Anvil". But what to name the namespace?

3. Some of my legacy projects have all source in the same directory, i.e. both 
source and header files are in the same directory. Others have both private and 
public headers in the same directory. How do I handle this with 
target_include_directories()? Preferably I would like to avoid reorganizing the 
file structure.

Regards

Björn

-- 

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