[Build-common-hackers] Bug#573350: Bug#573350: Bug#573350: cdbs: autotools-vars.mk shouldn't include makefile.mk

[Emilio Pozuelo Monfort]

Hi,

On 11/03/10 02:02, Jonas Smedegaard wrote:
> -dbg packages are not handled specially , but might "just work"(tm).

I guess for debugging symbols, but not for Python debug builds. For them, you
need to normally build the package with pythonX.Y-dbg as the interpreter, and
then rename the .so extensions to _d.so (so that python-dbg can find them). Also
those builds need to be done with -O0.

> The othe points certainly are handled.  That's the reason this class
> have been outside of mainline cdbs for so long: I extended makefile.mk
> and autotools.mk to support multiflavored builds,

That's very cool on its own :) I'll see if we can use it from those normal
packages that we build several times with different flags (e.g. gtk+2.0).

[snip]

> Your implementation is quite exciting to look at.  Parts of it I don't
> like - e.g. setting per-rule variables I feel should be avoided.  But
> some parts are interesting - like bug#500118 which I did not know
> about.  Obvious when you think about it, I just didn't until now :-P

You don't until you hit a bug ;) I was going to report a separate bug about it.

>> What about -dbg builds?
> 
> I have actually never tested -dbg packages with CDBS yet.  I believe I
> understand the general principle of such packages but have not yet had
> any use for them myself (I do not understand strace or debugging running
> C code).
> 
> so you can no doubt educate me on that part.

The idea is that debugging symbols are stripped from the main binaries to make
them smaller (since end users don't need them), and we ship them in separate
packages. Then if you need to debug something (say get a backtrace of a crash,
or step through the program while it's running), if you don't have the debugging
symbols, backtraces will contain almost zero information and you won't be able
to step through the code (as gdb won't know where things are). But gdb is able
to load detached debugging symbols, and that's what dbg packages contain.

However that's only a part of Python -dbg packages. There's also the python-dbg
interpreters, which cover different purposes (I'm not very confident with
python-dbg but the way to build them is pointed above).

> So how do we move from here?
> 
> 
> First off: Would you like to join the CDBS team?

Not for now, thanks. I can prepare a patch here and there and maybe at some
point join the team, but I dunno if I have the time right now.

> I feel that my implementation is the best one to work from - but
> obviously I am biased, so do tell me if you disagree!

Well, I dunno. Yours has the benefit that it reuses the existing (new) flavor
support. If it can do everything mine does (read: if I can get pygtk and
pygobject to work with it) then I'm okay with using yours.

> I will certainly cherry-pick (the idea from) your handling bug#500118

Cool.

> and will (later, I have my hands full at the moment) read it closer to
> try reveal other neat details too.  Would be very helpful if you could
> point out to me what you think are candidates for cherry-picking.

Mainly the python -dbg packages support. Also see
https://wiki.ubuntu.com/PyDbgBuilds

> I would appreciate help understanding and fixing any bugs in handling
> -dbg packages.  I believe some support is in cdbs already but have no
> idea what works and what don't.

CDBS supports normal -dbg packages (we have quite a lot in pkg-gnome), but
Python -dbg packages require special handling.

> Another thing I haven't gotten around to play with is parallelised
> builds.  In case you want a challenge ;-)

Doesn't CDBS support it already?

Cheers,
Emilio