This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: automation: problem with builddir != srcdir requirement


--- Nix <nix@esperi.org.uk> wrote: 

> On Thu, 2 Mar 2006, Claudio Fontana wrote:
> > I have a problem with current builddir != srcdir
> > requirement in glibc and recent versions of gcc.
> > Maybe you can give me an advice, or tweak your
> build
> > system around this problem.
> > 
> > This program is general enough to build most parts
> of
> > a GNU/Linux system automatically from source
> without
> > any overhead, or manual tweak.
> > 
> > The problem is that, while an user can read a
> message
> > like:
> > 
> > configure: error: you must configure in a separate
> > build directory
> > 
> > A program does not expect this.
> 
> Fix your program. It's trivial to write a build
> system with enough
> hookability to handle that.

If you can think of a good solution I am all ears.
Please send it to bug-sourceinstall@gnu.org,
or submit a patch to savannah, so we can discuss about
it there.

> (I did it and it took me much less than a
> day. That's the whole build system, not just the
> hooking. The hooking
> took about five minutes.

It took me about one year to build current extensible
architecture, the portable package management
system, the sourceinstall shared library, the clean 
exposed API, the command line front end and GTK front 
end. Maybe the project is something a bit different
than you think, but in any case you must be really
good, so why don't you join the project?

> It doesn't have your nifty
> frontend though,
> and I haven't dared distribute it yet.)

Aha, you don't like the fancy GTK front-ends.
You are lucky, you can use the fully functional
command line front-end, or even develop your own
frontend on the exposed API if you feel productive.

It's clearly stated in the project page and the
available documentation, which you probably already
read.

> Indeed, if a build system is to be of much use,

$ sourceinstall --list | wc -l
321

It is of decent use, at least to me, since my system
is mostly managed with this tool.

> it must be much *more*
> hookable, otherwise it couldn't possibly handle
> everything from GNOME's
> `run autogen.sh first'

Currently GNU Source Installer handles bootstrap-like,
autogen.sh-like scripts.
It is not a GNOME prerogative, it's common to many
codebases, and expecially to CVS checkouts.

> through to subversion's `only test after `make
> install' and not before' ---

subversion happens to be fully supported by GNU Source
Installer.

> and then there are things like the pre-
> autoconfiscated X11 to consider...

I build current X.org with GNU Source Installer
without any problem. It is not my goal to support
non-GNU standards, so imake is not supported, and
probably never will.

> FWIW I've found that greatest cross-build-system
> portability is obtained
> by cp -al'ing the source tree to a build tree and
> then doing a srcdir =
> objdir build in the common case,

I am doing this.

> and for special cases that cannot
> tolerate that (like GCC

not anymore. gcc-4.1 silently fixes the problem by
ensuring that builddir != srcdir himself.
I was hoping for a similar workaround in glibc.

>, glibc, and binutils

binutils have no problems in this sense.
However I am using recent versions, so maybe they
had a similar requirement in the past.

>) doing a `mkdir' instead.
> 
> With a little intelligence when finding configure
> (`look in the objdir,
> then in the srcdir if nothing is found in the
> objdir') this works
> completely transparently to the rest of the build
> system.

I found problems with this approach when I tried it,
but you can discuss it further, and possibly try it
with all the GNU projects (like I did, by chance), and
report your results to bug-sourceinstall@gnu.org.

> Let's not bug package maintainers with this. It's
> our job to adapt to
> *them*, not the other way around.

Well I do not want to "bug" GNU package maintainers,
and I'd be sad to know that the glibc people feel so.

I have built whole new build system, fixed dangerous
behaviours in uninstall rules,
added countless DESTDIR supports, and generally
offered all of my help to provide better build systems
in general, and to move to the GNU policies whenever
possible.

If you do not trust me, you might ask rms or the other
emacs maintainers if they felt "bugged" when I offered
them DESTDIR support for emacs, a fix for dangerous
uninstallation rules (on the way), and other fixes
still on the way.

You can discuss source installer development further
on bug-sourceinstall@gnu.org .

You can also submit bugs and patches directly in
savannah:
http://savannah.gnu.org/projects/sourceinstall/

Returning to the original question, I'd like to know
whether glibc would like to offer a workaround similar
to that in gcc-4.1, or if they would consider a patch
in that sense. 

Thanks,

CLaudio



	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]