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

[Angus Lees]

On Mon, 9 Mar 2015 at 00:50 Luca Bruno <lucab at debian.org> wrote:

> Speaking of which, have you ever tried the nodocs build-profile you
> committed?
> I think it doesn't work, as building a single binary package changes the
> DESTDIR so things are not anymore under debian/tmp.
> If that's the case, please refrain from committing untested stuff, or which
> doesn't match what the docs say, or which doesn't update existing docs
> where
> needed.
>

I think I'm a little offended by this :/  Yes, I tested nodocs and it
worked fine at the time I added this support.  And to repeat an earlier
apology, the docs you're referring to were written at a time when I was
working on my own packaging without co-maintainers, and were intended for a
consumer of the package as it would appear in Debian repositories.

I think I always had the luxury of extra packages back when I was testing
this however (split out editor configs, rust-{gdb,lldb}, runtime library
experiments, etc) which would explain why I'd never seen the issue you're
hitting.

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.

> Fwiw, my local branch has these changes:
> > - Move .so libs to standard /usr/lib
>
> Let's keep this on hold for the moment.
>

Ack.  It's in alioth gus/libdir if you want to take a look.  I'll continue
using it for my cargo packaging for now (when I get back to that), since it
fixes the `-C prefer-dynamic` issue without needing explicit changes in
cargo or elsewhere. Obviously we'll need to work out what we want to do
here before the cargo packaging can get uploaded.

> - Split rust-gdb into separate package
>
> Are you taking care of installing pretty-printers under PYTHONPATH and the
> loader in auto-load directory? We may want to add some versioning here to
> avoid future clashes, and propose something upstream which doesn't need
> `rustc --sysroot`.
>

Yes it's in PYTHONPATH, `info auto-load python-scripts` shows the right
directory, and `info pretty-printer` shows the pretty printer.  I also
patch it to avoid `rustc --sysroot` since we know where we've installed the
support files - again the patch is in alioth gus/libdir if you want to take
a look.

I think adding versioning is overkill given that the pretty printer is
quite basic and not overly tied to a particular version of rustc.  If it
/does/ change radically in the future somehow a) we can move to a versioned
scheme then, and b) I think we'd need to merge support into the same
version of rust-gdb anyway (sounds like a project that should happen
upstream) since you might be debugging a binary with linked code from mixed
rustc compilers.

> - 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).

I have _not_ tried compiling with the embedded llvm _and_ the additional
CFLAGS/CXXFLAGS.  It's conceivable that something in LLVM fails to compile
with -Werror, etc - although Sylvestre may be already building his llvm
with the recommended buildflags, I haven't looked.

Also: As I mention in the change, my current RUSTFLAGS setting assumes
rustc is linking using GNU ld.  This is currently the case for all
linux+openbsd rustc targets (search for linker_is_gnu) but is something to
keep in mind with ports to the more exotic Debian architectures.

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