[Pkg-rust-maintainers] Alpha2 upload [was: build profiles]

[Angus Lees]

On Tue, 10 Mar 2015 at 09:36 Luca Bruno <lucab at debian.org> wrote:

> On Monday 09 March 2015 03:51:46 Angus Lees wrote:
> > I think we should add `DESTDIR := $(CURDIR)/debian/tmp` to the top of
> > debian/rules to get consistent behaviour - or if we're going to accept
> the
> > rust-gdb split then that will also workaround the issue "for free".  I'll
> > commit the former right now in fact.
>
> I was actually passing --destdir to dh_auto_install as a workaround
> locally,
> but if nodocs profile builds with your commit that's equally ok.
>

Oh duh, _that's_ what was rewriting DESTDIR.  It takes about 2 hours for me
to run a test rebuild, and this explains why my first 2 attempts hadn't
worked :/

Heh, I'll upload a `dh_auto_install --destdir=$(DEB_DESTDIR)` change as
soon as this test run completes - unless you beat me to it :P

> > - Set buildflags according to policy (fixes relro lintian issue)
> > >
> > > Please thoroughly test this before committing, as I have this feeling
> that
> > > stuff will possibly break in subtle ways.
> >
> > Yeah, I agree - if you've got any ideas for additional test cases, I'd be
> > happy to try them out.  It passes the full "make check" suite, which
> > exercises the compiler quite extensively - including both small
> executables
> > produced and of course the rustc executable itself (which is built with
> > these additional flags).
>
> Cool! I am more concerned about cargo and other libs, which may happen to
> mix
> flags. But at this point, I don't have specific cases in mind, so don't
> bother
> too much.
>
> I saw your buildflags patch, just two quick notes:
>  * CFLAGS and CXXFLAGS seems to be usually included by mk/cfg/*.mk files,
>    except for x86_64-unknown-linux-gnu. I don't know the reason behind
> that,
>    but I suspect your platform.mk may results in double flags on other
>    platforms.
>

It looks like x86_64-linux-gnu and *-apple-ios don't have CFLAGS in the
platform makefiles.  I'm guessing they were perhaps the first few
platforms, so perhaps it's just cargo-cult coding and no-one has cleaned it
up yet (?).  I might send a patch upstream to do so...

The flags should be safe if they appear multiple times, but I agree it
would be nice not to duplicate them.  I originally modified the mk/cfg/*
files and can change the patch to do that way again if you'd like, but the
current one was (I think) the cleaner form and the one I'm intending to
propose upstream.

 * is there a reason for "Forwarded: no" or is it just a matter of (lack of)
>    time? I would be interested in getting upstream review on this and the
>    rationale behind the different handling in amd64.
>

Yeah, I meant Forwarded: "no" as in "not-yet", not "not-needed".  I'll send
something upstream now that we've confirmed it works.

Oh and re your concern about effects on cargo and other libs - the flags
only affect the current binaries being built(*).  There should be no change
to binaries that are in turn built by this rustc (and indeed, other
downstream Debian rust packages will need to duplicate some form of my env
settings - just like they would need to for C/C++).

(*) with a few exceptions.  For example `-z relro` makes additional memory
sections read-only at run-time for any code using the dylib, but afaiui
rust uses the runtime linker in quite a normal way and so shouldn't be
upset by this.

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150309/387f94ce/attachment.html>