This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: merge-with-binutils documentation is wrong/incomplete
Markus Werle wrote:
> Are You able to fill in the form?
> If yes: (yelling) PLEASE!!!! NOW!!!
We are /volunteers/, Marcus....
In a previous message, Markus Werle wrote:
> Phil Edwards wrote:
> > They can be unified. They can be built simultaneously. I do it all
> > the time.
>
> They can? Oh really? I am curious.
>
> Please fill in the following form:
> ------------------------------------------------
>
> [ ] gcc-_.__._ can be built simultaneously with binutils-_.__._
I use CVS GCC and CVS binutils.
> this is done with the following procedure:
>
> ____________________________________________
> (Your description here :-)
See below.
>
> [ ] a cvs checkout of binutils and gcc into the same directory
> and a successful build
> [ ] is not possible
^^
I don't believe it's possible using cvs 1.11. Checkout directories
cannot come from multiple repositories; that's just a limitation of cvs.
I /think/ this has been added for cvs 1.12. And I also think it's part
of Subversions, a GNU replacement for cvs.
> * on linux platforms we recommend binutils-_.__._ for gcc-2.95.3
I don't know; I personally don't track for 2.95.x for reasons which I
won't go into here.
> * for the hppa2.0w-hp-hpux11.00 platform we need
> [ ] I do not know which version
^^
I've never used an HP since I started hacking on gcc sources. Well,
apart from my trusty HP-48 calculator. :-)
HPUX 11 is being constantly worked on right now. If you need to use this
platform, you will absolutely need to use current CVS sources.
Anyhow... my crontab calls build_current_cvs. It calls relink.sh
and EGCSconfig. EGCSconfig is just there to save me some typing[*].
The relink.sh takes two directories called src and egcsworking, and creates a
third directory called unified: "src" is CVS binutils+gdb+some other stuff
(the src repository), "egcsworking" is the GCC repository which I make
changes to, and "unified" is a directory full of symlinks to the first two.
"unified" is then used as the source directory when configuring and building.
relink.sh doesn't do any work. The work is done by another script called
unify-src, which is more generic. (I have to create symlink trees for other
projects than just gcc, you see. It just happens that this is done so often,
and sometimes by hand, that relink.sh was made to encapsulate some work.)
Why all these different scripts? Enh... they spawned over time and across
my network of machines here. They can definitely be cleaned up.
They're all attached. I haven't tried to clean them up for presentation
or anything, so you'll need to change the directory names and remove
some extraneous crud. The ones you will most likely be interested in are
unify-src and relink.sh.
Luck++;
Phil
[*] It has been my firm and oft-repeated belief ever since I was an
undergraduate student that the sum goal of all Computer Science is to save
/me/ some typing. Not just people in general, but /me/. :-)
--
pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools. Fools are protected by more capable fools.
messy_scripts.tar.gz