Modular build: build.sh failing at libxcb, libX11 ...

[Jens Stroebel]

On Wed, Nov 07, 2007 at 03:13:52PM -0800, Jamey Sharp wrote:
> On 11/6/07, Jens Stroebel <dr-xorg at bcsoft.de> wrote:

  [...snip...]

>> then in libX11 (which gets caused by libtool trying to find *.la files
>> in $PREFIX/lib instead of $DESTDIR/$PREFIX/lib). We didn't continue at
>> that point and are using another method for xorg-libs ATM.
> 
> Similarly, Debian packages of libX11 are being built with
>   $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
> and that seems to work for them.
> 
> Oh, right, Debian installs the build dependencies on the build system
> first. I guess you want to do a series of DESTDIR installs without
> copying each installed module into the build environment immediately
> after it's built?

Indeed. This is what the build.sh script does without me interfering in
any way (except using DESTDIR of course).

It installs to $DESTDIR/$PREFIX and bombs at libxcb for the
first time, then would continue to do so at places...

While I understand that this is not normally possible with packages
depending on one another (because they are not to be found in the
DESTDIR), I'd thought that the script offering the setting of DESTDIR
was an indicator of using the script that way being possible
(by "without copying each installed module into the build environment"
you mean from $DESTDIR/$PREFIX to $PREFIX, right?)

It is usable that way after the proto+lib sections have finished (and
subsequently are installed), but not regarding them.

> I wonder if either unionfs or funionfs, perhaps combined with a chroot,
> will let you accomplish what you want?

I will keep this in mind when thinking about re-structuring our xorg
build in the near future.

As we build on linux (and on a dedicated build host), we're able to
"mount --bind" a directory to $PREFIX and umount it later to mount it to
another place for packaging. This can only be done as the root user,
though, which forces us to build-as-root the xorg-libs package (or
sudo-enable the build-user). This is one of the things we wanted to avoid.

Thanks for your comments anyway.

		[ ..... ]

On Thu, Nov 08, 2007 at 10:00:48AM +0100, Rémi Cardona wrote:
> Jamey Sharp a écrit :
>> On 11/6/07, Jens Stroebel <dr-xorg at bcsoft.de> wrote:
>>> While the other parts have no problem with DESTDIR, the build of
>>> xorg-libs has. It fails first in libxcb (which is pretty simple to fix
>>> by giving an environment variable to the make of it)

>> I don't understand. I routinely install libxcb using
>>   make DESTDIR=... install
>> and it works for me. What are you doing that doesn't work?

>>> then in libX11 (which gets caused by libtool trying to find *.la files
>>> in $PREFIX/lib instead of $DESTDIR/$PREFIX/lib). We didn't continue at
>>> that point and are using another method for xorg-libs ATM.

>> Similarly, Debian packages of libX11 are being built with
>>   $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
>> and that seems to work for them.

> Gentoo works the same way, using "make DESTDIR=" and then copying the
> files to the root filesystem.

But the build.sh script reachable via the ModularDevelopersGuide wiki
page does not do so (and in my opinion it would defeat the purpose of
DESTDIR builds if it did). Executed, it tries to build sequentially
along the dependencies list. After the lib section, this works fine, so
the lib-"slice" of our xorg build is the only one unable to do DESTDIR.

> Jens, basically, I think you're bending DESTDIR for something it
> wasn't really meant for.

Regarding the DESTDIR mechanism alone, I would say you're right there.
It's not expected of packages which support DESTDIR to also support all
their dependencies living under DESTDIR so you could build the whole
distribution just in that DESTDIR without installing :) .

Because of the existence of the build.sh script and it's DESTDIR
possibility I thought it could run using DESTDIR, though...
But it doesn't do so if started from the beginning. I just wanted to
make sure that this is "expected behavior".

> If you use DESTDIR, you will still have to put them in the original
> $prefix dir at some point if you want other libs/programs to find them
> correctly. Trying to work around that is hacky at best.

OK, I'd say you're again right here ...

	[..different approach of packaging snipped..]

> Hope that helps.

Not exactly, but thanks anyway, as it made me think and may lead to a
new approach lateron.


Thanks both of you for taking the time to busy yourself with this.

		greets,
		   jens
-- 
dr-xorg at bcsoft.de
		23.....56.......drifting
It hurts sometimes more than we can bear.
If we could live without passion, maybe
we'd know some kind of peace.
But we would be hollow.
Empty rooms, shuttered and dank...
Without passion, we'd be truly dead.