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] |
--- 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] |