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

2020-04-14 Thread Riccardo Mottola
Update of bug #52518 (project gnustep):

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


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




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

2018-03-01 Thread 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:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep


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

2018-02-28 Thread 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:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep


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

2018-01-24 Thread Riccardo Mottola
Update of bug #52518 (project gnustep):

  Status:None => In Progress


___

Reply to this item at:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep


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

2018-01-08 Thread Richard Frith-Macdonald
Update of bug #52518 (project gnustep):

Category: Base/Foundation => Application


___

Reply to this item at:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep


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

2018-01-08 Thread Richard Frith-Macdonald
Update of bug #52518 (project gnustep):

Category: Application => Base/Foundation


___

Reply to this item at:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep


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

2018-01-06 Thread 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
 but it's entirely up to you whether to follow it.

___

Reply to this item at:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep


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

2018-01-06 Thread 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:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep


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

2018-01-02 Thread 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  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  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:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep


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

2017-12-31 Thread 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  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:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep


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

2017-12-31 Thread Ivan Vučica
Update of bug #52518 (project gnustep):

 Assigned to:None => ivucica


___

Reply to this item at:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep


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

2017-12-31 Thread 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:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep


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

2017-11-26 Thread 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:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep


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

2017-11-26 Thread Yavor Doganov
URL:
  

 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



___

Reply to this item at:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep