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.

Dito for any over "Thank good I don't have to write list handling
code -- let's reinvent make a couple of more time!" tool.