Follow-up Comment #7, bug #25357 (project gnustep):
Yes ... well, not that there is anything very clever that
we can do here. :-(
I'm not too convinced that people would really use
a ./configure which is located two or three directories
below the top-level to fix a mistake they did in the
options they passed top-level ... they are most likely
to just try again top-level with different options. ;-)
(That's what I do as a user. It's too risky to try
being clever with configure of software you don't very well)
I also looked a bit into this and I was wondering ...
aren't ./configure scripts in subdirectories slowing down
the configure process a lot ? It seems that they are
both very slow to start, and they also run a lot of tests
that are already done top-level.
On my old machine, ./configure takes about 40% of the time
required for a full-build of gnustep-base. That's a massive
amount of time considering how little it is doing (total
time is just below 5 minutes, and ./configure takes about
2 minutes).
Maybe moving all the tests top-level in a single configure
(using includes to keep the code organized ?) could speed
things up ?
It might also simplify things, in terms of configure stuff
being all in one place instead of spread around in many
files in subdirectories.
Anyway I don't have a strong opinion - if we want to use
subdirs, let's do that.
Thanks
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?25357>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
