[bug #52518] [GWorkspace] Unnecessarily complex build system

[Yavor Doganov]

URL:
<http://savannah.gnu.org/bugs/?52518>

Summary: [GWorkspace] Unnecessarily complex build system
Project: GNUstep
Submitted by: yavor
Submitted on: Sun 26 Nov 2017 09:11:13 PM EET
Category: Application
Severity: 3 - Normal
Item Group: Change Request
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

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.



_______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Sun 26 Nov 2017 09:11:13 PM EET Name:
0001-Simplify-build-system.patch.xz Size: 49KiB By: yavor

<http://savannah.gnu.org/bugs/download.php?file_id=42493>

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?52518>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Yavor Doganov]

Follow-up Comment #1, bug #52518 (project gnustep):

Thinko, I wanted to say "--no-undefined" instead of "--as-needed".

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?52518>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Ivan Vučica]

Follow-up Comment #2, bug #52518 (project gnustep):

I am very much in favor of applying this, but I'm insufficiently familiar with
GWorkspace to say if there is any reason for why it was done this way.

I'll create a PR and send it for review.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?52518>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Ivan Vučica]

Update of bug #52518 (project gnustep):

Assigned to: None => ivucica


_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?52518>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Ivan Vučica]

Update of bug #52518 (project gnustep):

Assigned to: ivucica => rmottola

_______________________________________________________

Follow-up Comment #3:

I created a PR at https://github.com/gnustep/apps-gworkspace/pull/2 if you'd
like a diff, but I am fine with reviewing here instead (given that GH is
nonfree, you might not like using it).

(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:
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.

I'll let Riccardo take a look at this too.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?52518>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Yavor Doganov]

Follow-up Comment #4, bug #52518 (project gnustep):

(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).

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?52518>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Riccardo Mottola]

Follow-up Comment #5, bug #52518 (project gnustep):

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
unexpected consequences.
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
at all.

Also, I am now confused by what I should review, Yavor or Ivan's work.
I would have preferred a more gradual approach.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?52518>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Yavor Doganov]

Follow-up Comment #6, bug #52518 (project gnustep):

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.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?52518>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Richard Frith-Macdonald]

Update of bug #52518 (project gnustep):

Category: Application => Base/Foundation


_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?52518>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Richard Frith-Macdonald]

Update of bug #52518 (project gnustep):

Category: Base/Foundation => Application


_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?52518>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Riccardo Mottola]

Update of bug #52518 (project gnustep):

Status: None => In Progress


_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?52518>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Riccardo Mottola]

Update of bug #52518 (project gnustep):

Status: In Progress => Ready For Test
Open/Closed: Open => In Test

_______________________________________________________

Follow-up Comment #7:

I tweaked "distclean" a little bit more and fixed a couple of more exotic
platforms.
Seems fine on most places where I tested (different Linux, NetBSD, FreeBSD,
OpenBSD, Solaris)

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?52518>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Yavor Doganov]

Follow-up Comment #8, bug #52518 (project gnustep):

I didn't observe any problems on the platforms I have access to.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?52518>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/