On 26/11/2015 22:50, Rainer Weikusat wrote:
> Svante Signell <svante.signell@???> writes:
>> On Thu, 2015-11-26 at 19:36 +0000, Roger Leigh wrote:
>>> On 26/11/2015 17:53, Svante Signell wrote:
>>>> On Thu, 2015-11-26 at 17:04 +0000, Roger Leigh wrote:
>>>>> On 26/11/2015 15:00, Svante Signell wrote:
>>>>>> On Thu, 2015-11-26 at 15:33 +0100, aitor_czr wrote:
>>>>>>>
>>>>>> Hi, what's wrong with plain GNU make, and the GNU auto-tools?
>>>>>
>>>> Then you are a happy user of cmake. I'm working on porting packages for
>>>> GNU/Hurd and every time when I encounter packages using cmake the confusion
>>>> increases. It seems almost impossible to find out where to make changes and,
>>>> the build process is not traceable. (maybe It's just me :( )
>>>
>>> You looked at CMakeFiles/CMake(Output|Error) ? Most stuff should be
>>> logged there. And if you need to trace, message(WARNING) will print a
>>> trace along with the diagnostic.
>>
>> Well, as long as you work with configure.ac, Makefile.am and confiugre.h.in
>> level for files you won't have any problems with make/autotools. The rest is
>> mostly hidden (and by now stable) from a user perspective.
>
> From a user perspective, auto* is a major PITA because ten open source
> projects using auto* will require some power-of-ten combinations of
> mutually incompatible version of autothis, autothat and
> autosomethingelse (But for as long as the developers don't have to read
> the make docs, who cares!) and this doesn't even enter into "independent
> developer trying to use the code" territory where things start to become
> really nasty.
>
> In case this still happens to be different for CMake, it will fix itself
> over time as more (mutually incompatible) versions of that end up being
> used by more software.

They already thought about this, and have a versioning and policy
mechanism in place for forward and backward compatibility. You specify
the minimum required version, and you can also toggle deprecated or new
features on or off on a per-feature basis.

While the autotools require the upstream developer to have all the tools
of the correct version installed, to embed the generated build files in
the release tarfile, cmake requires a recent enough version to be
installed on the machine of the person building the software.

In practice, what this means is that the developer needs to pick a
lowest common denominator cmake version for the platforms they wish to
support, and if you use an older system you need to get a newer version
of cmake. As an example, I currently use 2.8.6 as a minimum. It's
supported by anything from the last few years, but I'm going to update
to 3.2 in the next few weeks since I now need some newer features. As a
developer, the tradeoff between the features you can use and the version
you require is yours to make though.


Regards,
Roger