Build system

[czarkoff]

Autoconf is an overkill for the configuration needs of xclip. This is particularly true now, as xclip is developed on Github and release tarballs are just snapshots of source tree.

This pull request removed auto* stuff and adds static Makefile. Installation instructions in INSTALL file are changed to provide more information about customizing the build.

[astrand]

-1. In general, I think that most projects should either use Autoconf or CMake.

[czarkoff]

This PR is not closed yet, so I guess I should argue a bit for it. Autoconf and friends make most sense when there is actually something to configure. In terms of dependencies and build time configuration xclip is rather straight-forward and uses a well-defined subset of modern Unix facilities, so there is not much difference between supported platforms. That makes configuration task trivial enough to make autoconf an overkill.

Makefile from this PR is compatible with both GNU and BSD make, and uses very little beyond POSIX make syntax. It is easy to read and to maintain, it is easier to change if needed, it is easier to debug, and it is more flexible for the end users.

[astrand]

Yes, I kept this PR open, in order to allow further discussion and feedback. It's correct that the xclip configure.ac is fairly small, but there's still a few things that needs to be done. For example, we are checking for Xmu/Atoms.h and Intrinsic.h, plus iconv etc. I believe it's better to have checks and error messages through Autoconf, than GCC build errors. Another advantage is that the version number is coded in a common location.

[czarkoff]

Sorry, I don't see how this:

$ time sh -c 'AUTOCONF_VERSION=2.69 AUTOMAKE_VERSION=1.15 ./bootstrap && ./configure'   
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking whether -R must be followed by a space... no
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for strip... strip
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking X11/Xmu/Atoms.h usability... no
checking X11/Xmu/Atoms.h presence... no
checking for X11/Xmu/Atoms.h... no
configure: error: *** X11/Xmu/Atoms.h is missing ***
    0m12.12s real     0m05.04s user     0m03.55s system

is better then this:

$ time sh -c 'AUTOCONF_VERSION=2.69 AUTOMAKE_VERSION=1.15 make'                      
cc -I/usr/X11R6/include -DPACKAGE_NAME=\"xclip\" -DPACKAGE_VERSION=\"0.13\" -o xclib.o -c xclib.c
cc -I/usr/X11R6/include -DPACKAGE_NAME=\"xclip\" -DPACKAGE_VERSION=\"0.13\" -o xcprint.o -c xcprint.c
cc -I/usr/X11R6/include -DPACKAGE_NAME=\"xclip\" -DPACKAGE_VERSION=\"0.13\" -o xclip.o -c xclip.c
xclip.c:32:27: error: X11/Xmu/Atoms.h: No such file or directory
xclip.c:38: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'opt_tab'
xclip.c:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'opt_db'
xclip.c:61: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'rec_val'
xclip.c: In function 'doOptMain':
xclip.c:72: error: 'opt_db' undeclared (first use in this function)
xclip.c:72: error: (Each undeclared identifier is reported only once
xclip.c:72: error: for each function it appears in.)
xclip.c:72: error: 'opt_tab' undeclared (first use in this function)
xclip.c:76: error: 'rec_val' undeclared (first use in this function)
xclip.c: In function 'doOptSel':
xclip.c:154: error: 'opt_db' undeclared (first use in this function)
xclip.c:154: error: 'rec_val' undeclared (first use in this function)
xclip.c: In function 'doOptTarget':
xclip.c:193: error: 'opt_db' undeclared (first use in this function)
xclip.c:193: error: 'rec_val' undeclared (first use in this function)
xclip.c: In function 'main':
xclip.c:515: error: 'opt_tab' undeclared (first use in this function)
xclip.c:517: error: 'XrmoptionSepArg' undeclared (first use in this function)
xclip.c:535: error: 'XrmoptionNoArg' undeclared (first use in this function)
*** Error 1 in /home/czarkoff/coding/xclip (Makefile:31 'xclip.o')
    0m00.75s real     0m00.33s user     0m00.12s system

FWIW successful build on my machine takes much less time then autoreconf and configure take to fail.

Also note, makefiles are much easier to read then configure script.

P.S.: with Makefile-based configuration version number is also coded in common location.

[astrand]

Autoconf is better for an unknown user, because in that example, this is the last output line:

configure: error: * X11/Xmu/Atoms.h is missing *

In your second example, the last line is:

xclip.c:535: error: 'XrmoptionNoArg' undeclared (first use in this function)

...which can make you think that there's an error in the source code. Wrt the version number, the point was that it's better to have it in a location that other open source project uses. Among open source projects, it's more common with Autotools than simple Makefiles.

[czarkoff]

@astrand: well, I guess by "unknown user" you mean "inexperienced user", right? Well, if that's your concern, it may be addressed directly. In my last commit I added a configure target for Makefile, which checks for those two header files. The library checks are still redundant to linker failures. (And the two you actually have are redundant to header test and POSIX.)

 $ make
<stdin>:1:27: error: X11/Xmu/Atoms.h: No such file or directory
*** Error 1 in /home/czarkoff/coding/xclip (Makefile:39 'check-headers': @(for h in X11/Xmu/Atoms.h X11/Intrinsic.h; do echo "#include <$h>"...)

[czarkoff]

ping

[astrand]

Hi, I saw your post, but at this time, I will not change build system.

[mimi1vx]

@czarkoff autoconf/ cmake etc is always better than buggy custom build system .. for any distribution packager

[hackerb9]

Autoconf and friends make most sense when there is actually something to configure. In terms of dependencies and build time configuration xclip is rather straight-forward and uses a well-defined subset of modern Unix facilities, so there is not much difference between supported platforms. That makes configuration task trivial enough to make autoconf an overkill.

Hi @czarkoff,

While I love the beauty of your simple Makefile and I give you kudos for making it work on BSD and GNU systems, I think autotools are better here. The author of xclip has already spent the initial effort to setup autoconf, which is the hardest part. And autoconf is not without merit.

Even if xclip itself doesn't evolve, future machines may have different capabilities/incompatibilities that autoconf will help with.

There was an age before autoconf where people wrote Makefiles that worked "everywhere", meaning all the computers presently available. But they couldn't account for future changes as UNIX systems evolved or diverged causing them to break. Every project's Makefile had to be rewritten with ugly hacks. It was annoying, redundant work and completely unnecessary. Autotools saved us from that. Instead of every project having to account for the new changes, you only need a new version of autotools and — voilà — you're compiling on a new system as if nothing changed.

I don't want to discourage you from contributing to projects. I know it can be frustrating when you spend time and effort trying to contribute back to a project only to be flatly rejected. I hope you know that, even if the manner seems brusque, your work is appreciated.