bugGNUstep - Bugs: bug #25357, document instllation domain...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #25357: document instllation domain configure option

Submitted by:  Riccardo Mottola <rmottola>
Submitted on:  Mon 19 Jan 2009 11:55:30 AM UTC  
 
Category: MakefilesSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

(Jump to the original submission Jump to the original submission)

Mon 16 Feb 2009 01:10:14 PM UTC, comment #8:

Well, it works so I guess we can close the issue.

Thanks

Nicola Pero <nico>
Project Member
Thu 22 Jan 2009 03:39:29 PM UTC, comment #7:

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

Nicola Pero <nico>
Project Member
Thu 22 Jan 2009 02:30:31 PM UTC, comment #6:

I suppose the documentation could just be in the top-level configure script ... on the basis that if you are executing the lower level script directly, you probably ought to know what you are doing anyway. The idea of the lower level stuff was to be able to change path information without having to rebuild the whole pacakge, so it's something for an automated system or for an expert anyway.

Richard Frith-Macdonald <CaS>
Project Member
Thu 22 Jan 2009 02:25:42 PM UTC, comment #5:

Is it a good idea to have the documentation for the same
./configure flags in two different places though ? It sounds
like it could easily get messy/out of sync. ;-)

Pity autoconf is such a kludge, so it's hard to organize things
nicely. :-(

Thanks

Nicola Pero <nico>
Project Member
Wed 21 Jan 2009 06:51:15 AM UTC, comment #4:

The flags should appear at the top level now ... do they work for you?

Richard Frith-Macdonald <CaS>
Project Member
Mon 19 Jan 2009 02:10:35 PM UTC, comment #3:

there is ./configure --help=recursive but its not entirely obvious that there is hidden flags

matt rice <ratmice>
Project Member
Mon 19 Jan 2009 02:10:33 PM UTC, comment #2:

I assumed autoconf would propogate options from a subsidiary config file to the top level, but I guess not.

Can we define the options in the top level and have them passed on to the subsidiary so that you can configure from both levels (ie so you can reconfigure path handling without having to reconfigure everything else too)?

Richard Frith-Macdonald <CaS>
Project Member
Mon 19 Jan 2009 01:48:27 PM UTC, comment #1:

Yes, all the GNUstep pathconfig options have disappeared from
gnustep-base's top-level ./configure help in trunk. :-(

I think that's because Richard moved the configuration options
into a new configure file deeper inside Source. That seemed
like a reasonable thing to do, but the side effect of
removing all the general pathconfig options help from top-level
is not great.

Also because, these are the non-standard, GNUstep-specific
options where help is most strongly needed ;-)

Maybe we could bring back the ./configure options to top-level
while leaving the makefile fragments and configure fragments
where they are ?

Thanks

Nicola Pero <nico>
Project Member
Mon 19 Jan 2009 11:55:30 AM UTC, original submission:

I'd like that when running ./configure --help con base I'd be reminded of the --with-installation-domain option

Riccardo Mottola <rmottola>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by ratmice (Posted a comment)
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by nico (Posted a comment)
  • -unavailable- added by rmottola (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 16 Feb 2009 01:10:14 PM UTCnicoOpen/ClosedIn Test=>Closed
    Wed 21 Jan 2009 06:51:15 AM UTCCaSStatusNone=>Fixed
      Open/ClosedOpen=>In Test
    Mon 19 Jan 2009 01:48:27 PM UTCnicoSeverity1 - Wish=>3 - Normal

    Back to the top


    Powered by Savane 3.1-cleanup1