Summary: [GWorkspace] Unnecessarily complex build system
Submitted by: yavor
Submitted on: Sun 26 Nov 2017 09:11:13 PM EET
Severity: 3 - Normal
Item Group: Change Request
Assigned to: None
Discussion Lock: Any
GWorkspace's build system is incredibly convoluted: there are 56 (!) nested
configure scripts, 14 config headers and 59 makefiles that are generated,
while only a small number of them have @something@ to be AC_SUBST'ed. I tried
to find out whether there is specific reason for this approach, but couldn't
figure out why it was done this way. Perhaps it remained so from Enrico's
days and nobody had the chance to clean it up.
The only legitimate reason for using AC_CONFIG_SUBDIRS is when software in
sub-directories is distributed as stand-alone packages (e.g., separate
self-contained tarballs for the frameworks, extractors, viewers, ddbd and the
rest of the tools) That is not the case and I doubt it ever will be.
The attached patch, while rather intrusive, reduces the time for running
"./configure --enable-gwmetadata" more than 10 times and reduces the size of
the tarball with approx 2.5 MB. It also fixes quotation of Autoconf macros in
some places, replaces the obsolete AC_TRY_RUN macro with AC_RUN_IFELSE and
fixes the build with LDFLAGS=-Wl,--as-needed.
Please let me know if something doesn't work as expected or if you have some
other remarks. Thanks.
(1) Side remark: Interesting that you're explicitly stating FND_LIBS. I guess
it makes sense for libraries.
(2) I like the change in GWMetadata/gmds/gmds/GNUmakefile.preamble to move to
ADDITIONAL_TOOL_LIBS += -lsqlite3
but I am not sure moving -L flags in
GWMetadata/gmds/gmds/GNUmakefile.preamble.in is correct:
ADDITIONAL_TOOL_LIBS += @SQLITE_LIB_DIRS@
Also, are these one and the same? It's confusing that @SQLITE_LIB_DIRS@ has a
library and not the -L in it. It's also slightly confusing that both
GNUmakefile.preamble.in and GNUmakefile.preamble are and were submitted. I
think I'll delete the GNUmakefile.preamble.
(3) In OpenOfficeExtractor.m, the inclusion of <config.h> is almost certainly
wrong. Is there a system header called config.h? Did you mean local header
"config.h"? I'll update this. Same in Resizer.m.
(1) FND_LIBS (and GUI_LIBS) is recommended by the GNUstep Make manual instead
of hardcoding -base/-gui as these variables are defined to the appropriate
value on Apple and non-Apple systems.
(2) -L flags belong to LIBS and not LDFLAGS. On some systems (proprietary
Unix flavors, I guess), the library will not be found if it's in a
non-standard directory and -L <dir> does not appear immediately before -llib.
GNUmakefile.preamble must be deleted as it is a generated file, I'm sorry to
have missed that.
(3) The Autoconf manual recommends to use <config.h> with the proper -I
option, and that it should be included before any other system headers.
Nearly all GNU packages do this, it is perfectly safe. The rationale behind
this recommendation is for predictable results in out-of-tree builds: If you
#include "config.h", the preprocessor will search first the directory where
the source file is located, IOW srcdir. If there's a stale config.h there, it
will be used instead of the freshly generated config.h (config.status always
writes output files in builddir).
I have difficulties reviewing and accepting such a large patch and its testing
will require lots of regression on different platforms. I spent hours tweaking
the existing system of Enrico for many small issues. A mega-patch might have
Especially inspectors were carefully tuned.
The current build system may be convoluted, but it is tested on 3 BSDs,
Solaris, different Linux flavours and even HURD. Are there open issues?
Only the MDKit
I may add that as far as I know gnustep-make does not support off-tree builds
Also, I am now confused by what I should review, Yavor or Ivan's work.
I would have preferred a more gradual approach.
What makes the patch large is the gazillion configure scripts. If you filter
them out it should be fairly easy to review. There are also many duplicated
configure checks and even macro definitions that the patch cumulates at one
place. I can split it in 56 chunks if you want, but it'll certainly take much
more time to review and test them one by one.
You can also test it on all other platforms you have access to, it just takes
time. If anything is broken I'm confident I can fix it quickly.
GNUstep Make doesn't support out of tree builds only if you follow the usual
practice for writing GNUstep makefiles. But if you use autoconf to generate
them and the vpath GNU make directive you get VPATH builds out of the box and
without too much effort. It's a matter of good practice to #include
<config.h> but it's entirely up to you whether to follow it.