[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ANN: base/make Version 1.5.1

From: Nicola Pero
Subject: Re: ANN: base/make Version 1.5.1
Date: Mon, 25 Nov 2002 18:26:17 +0000 (GMT)

> >    * New 'make strings' target for localization support.
> >
> >    * Speed improvements.
> Great.  Does this include not putting tons of non-existent directories 
> into the $PATH (especially on MinGW)?

I'm not familiar with MinGW - but you seem to say the problem is there
also on other platforms - can you be more precise on what the problem is ?

Maybe you are referring to the xxx/Local/Tools/yyy and
xxx/Network/Tools/yyy directories.

Then, well here is the long explanation - 

 - gnustep-make supports four domains: System, Local, Network and User.

 - gnustep-make does not create all directories in the domains, but only
dirs in the System domain (and even there, mostly to give a clear example
of what the directory structure is).  it creates directories in the other
domains lazily, only when they are needed.  For example, if you install an
application in GNUSTEP_NETWORK_ROOT for the first time, only then it
creates GNUSTEP_NETWORK_ROOT/Applications.

 - gnustep-make adds paths for all domains into the PATH, so that all
domains are immediately used as soon as you put something in them.

If you want, you can configure gnustep-make to use less domains.  You
could collapse the system/local/network domains together, for example.  

Check the ./configure script of gnustep-make.  If you collapse some
domains together, the number of directories in PATH (and LD_LIBRARY_PATH
and other dirs) should be - hopefully :-) - much smaller. :-)

It shouldn't be a problem to collapse together local and network, or
system and local etc - the user domain is the only really special one -
it's best not to collapse the system and user domain together unless, of
course, unless you know what you are doing :-)

If I misunderstood your question (I'm not familiar with the MinGW port),
would you be so kind as to expand a bit more in details on what the
problem is ?


> Have the strange path issues on MinGW been addressed?

I'm not sure about that.  I really need to try the MinGW port sooner or

reply via email to

[Prev in Thread] Current Thread [Next in Thread]