Le 01/05/2019 à 18:23, aitor_czr a écrit :
On Thu, 2015-11-26 at 17:04 +0000, Roger Leigh wrote:
On 26/11/2015 15:00, Svante Signell wrote:
Hi, what's wrong with plain GNU make, and the GNU auto-tools?
Nothing is wrong with "plain make", providing that it meets your needs.
But often you want more than plain make can offer. There's plenty to
criticise with the autotools, the baroque complexity being the primary
one. CMake is a big upgrade from the autotools; it's vastly more
featureful and powerful, has better portability for modern systems, and
still works with make when generating Makefiles. The autotools have
failed to keep up to date with modern portability requirements; the
capabilities CMake has to offer are unmatched at the present time,
though it also has its own warts. After 15 years of autotools use, I
converted all my stuff to CMake over the last two years, and I'm not
looking back.
I haven't talked against autotool for several years, I think (~:
In the case of this application, I don't think there's a need for
configuration and portability because the program is completely
Linux-oriented and absolutely depends on features which only exist in
the Linux kernel (/sys, /proc, inotify, signalfd). I've no idea on
wether it is portable to another OS and don't care much.
For what concerns portability to other libcs, I consider a must to
stick to the POSIX standard and not bloat the program with switches
depending on which library and which version is used. If the program
relies on any non-standard feature, I consider it a bug which I'm
willing to correct.
There might be an issue with the location of the installed files
which may depend on the distro; then, well, it's a job for the packager.
Maybe it would help to have the location of the default config file set
by a #define; this is something I can do.
Didier
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
