Re: gcc rules file
In gcc-2.95.1-0pre1 (changelog entry at eom), the following issues are
addressed:
Daniel Jacobowitz writes:
> > - remove the gcc_dirs needed for multilibs.
>
> Definitely, now that I've got the multilib patches working better.
> Maybe a multilib() macro.
done. although still in debian/rules2 as comments.
> > - separate the rules file in some smaller chunks? or restructure it?
>
> Some pieces of it, definitely, should be more modular.
done. debian/rules now contains rules to unpack the tarballs, patch
the sources and generate debian/control and debian/control.parameters.
debian/rules.{unpack,patch} are included by debian/rules.
debian/rules.defs now contains the "configuration" (selection of
packages) and is included in both debian/rules and debian/rules2.
debian/rules.conf is called from debian/rules to build debian/control
and debian/rules.parameters.
> > - rework the patch system and submit it to dh_make and/or debhelper as
> > an example.
>
> Or hash out a new source package format finally.
not yet done ;-) But there is definitely a need for it, if you have to
extract build information from the sources, before they are unpacked,
you cannot use the "var := $(shell ...)" constructs in the primary
rules file anymore.
Joel Klecker writes:
> 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 :)
done. However the dependencies are still not right. Have to change this.
> >- 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.
Is this really a problem? A workaround would be to include
dpkg-architecture into gcc's debian/scripts.
> 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.
done. There is a speed up, but there are new problems (see above).
> - 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".
done. Although I did not split off the patches in arch- and
indep-patches.
What needs to be done (besides the topics mentioned in this thread:
- having a look at the still open C++ bugs.
- build libgcj (and gcj?) only for architectures, where the Boehm
garbage collector is available.
[I already have seen an gcc upload for arm; hope Jim did not some
major changes to the debian/* files ;-)]
gcc (2.95.1-0pre1) unstable; urgency=low
* Updated to cvs 19990815 gcc-2_95-branch; included install docs and
FAQ from 2.95 release; upload source package as well.
* Source package contains tarballs only (gcc, libg++, installdocs).
* debian/rules: Splitted into debian/rules{,.unpack,.patch,.conf,2}.
* debian/gcc.postinst: s/any key/RETURN; warn only when upgrading from
pre 2.95 version; reference /usr/doc, not /usr/share/doc.
* Checked syntax for attributes of functions; checked for #35068;
checked for bad gmon.out files (at least with libc6 2.1.2-0pre5 and
binutils 2.9.1.0.25-2 the problem doesn't show up anymore).
* debian/patches/cpp-macro-doc.dpatch: Document macro varargs in cpp.texi.
* gcc is primary compiler for all platforms but m68k. Setting
severity of #22513 to fixed.
* debian/patches/gcc-default-arch.dpatch: New patch to enable generation
of i386 instruction as default (fixes #42743).
* debian/rules: Removed outdated gcc NEWS file (fixes #42742).
* debian/patches/libstdc++-out-of-mem.dpatch: Throw exception instead
of aborting when out of memory (fixes #42622).
* debian/patches/cpp-dos-newlines.dpatch: Handle ibackslashes after
DOS newlines (fixes #29240).
* Fixed in gcc-2.95.1: #43001.
* Bugs closed in this version:
Closes: #11525, #12253, #22513, #29240, #35068, #36182, #42584, #42585,
#42602, #42622, #42742 #42743, #43001, #43002.
Reply to: