Re: gcc rules file
At 23:22 +0200 1999-08-06, Matthias Klose wrote:
- separate the rules file in some smaller chunks? or restructure it?
I'd like to see it separated into more targets, especially configure,
build, install. People on slower machines (heck, even on my fast
machines, a make install of gcc is time-consuming) will be thankful
if things like the install step don't have to be repeated more than
once when simply working on the packaging. ** I will probably tackle
this one too :)
- add support for pgcc? pgcc is distributed as a patch to gcc-2.95, so
this is not a technical problem.
I'm not sure it's worth it, once new_ia32_branch is ready, pgcc is
probably gonna lose its reason for existance, and there's not really
enough benefit to Debian as a whole (IMHO) to expend the effort on
accommodating pgcc.
- honor the DEB_* variables when set in the environment.
That won't work without passing -e to make. That's probably a bad idea.
I think using dpkg-architecture -q<var> in the makefile to set the
variables will honor the environment, but dpkg-architecture's docs do
not recommend this route until we have source depends so that the
source package can depend on a new enough dpkg-dev.
I have a few more items:
- unpack sources at binary package build time rather than having a
large, non-pristine source tree. This has two benefits, first the
pristine source aspect, and second it significantly speeds up
dpkg-source -b.
- Add a new class of packages: CROSS, this type would have a package
suffix of -$DEB_HOST_GNU_TYPE and would use the standard
${prefix}/${target_alias}/ directory structure and
${target_alias}-<tool> binaries and man pages. I plan to make this
the basis of a 'gcc-cross-source' binary package that would install a
gcc source tree in /usr/src and provide some scripts to automate the
process of building a cross-compiler for any Debian architecture.
I plan to tackle both of these items, with the second being a lower priority.
One more:
- Avoid using the DEB_*_ARCH variables, and use the DEB_*_GNU_*
variables instead. The latter style are more fine-grained, the former
is a rather coarse and Linux-centric view of the world. For example,
say you have a sparc-specific patch that affects any
"DEB_HOST_GNU_TYPE" that uses a sparc processor, you could key off of
DEB_HOST_GNU_CPU = sparc and you'd take care of applying that patch
for DEB_HOST_GNU_TYPEs of "sparc-gnu" or "sparc-linux" or
"sparc-netbsd" or whatever, whereas DEB_HOST_ARCH = sparc only takes
care of "sparc-linux".
--
Joel Klecker (aka Espy) Debian GNU/Linux Developer
<URL:mailto:jk@espy.org> <URL:mailto:espy@debian.org>
<URL:http://web.espy.org/> <URL:http://www.debian.org/>
Reply to: