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