[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#599206: dpkg-cross should leave files in converted package

On Wed, 6 Oct 2010 13:22:08 +0200
Loïc Minier <loic.minier@linaro.org> wrote:

> On Tue, Oct 05, 2010, Neil Williams wrote:
> > This script is a "build-tool", it is not a "cross-build-dependency" in
> > that it is not a header file, it is not a pkg-config file and it is not
> > used when linking the cross built application. The file is therefore
> > not architecture-dependent and cannot be handled by dpkg-cross.
>  It is a build tool, but it's specific to the target architecture

Non-standard build configuration - you'll need to discuss with upstream
just how this is meant to support cross-compilation. Probably just have
to patch the source to make this script truly cross-platform by having
all the variables defined and selecting according to the
dpkg-architecture environment variables.

>  The fact that it's not a header, not a pkg-config file, and not used
>  when linking cross built applications doesn't imply that it is
>  architecture independent.

So ask upstream to migrate to pkg-config or adapt their script to be
>  I diffed tclConfig.sh on armel and amd64:
> @@ -18,10 +18,10 @@ TCL_MINOR_VERSION='5'
>         TCL_PATCH_LEVEL='.8'
>         # C compiler to use for compilation.
> -       TCL_CC='x86_64-linux-gnu-gcc'
> +       TCL_CC='arm-linux-gnueabi-gcc'
>         # -D flags for use with the C compiler.
> -       TCL_DEFS='-DPACKAGE_NAME=\"tcl\" -DPACKAGE_TARNAME=\"tcl\" -

.... a wdiff would have been a lot more helpful here. Exactly what
changed on those long, long lines?

> > If having the amd64 package around causes trouble, discuss with the tcl
> > maintainers whether the script can be put into a -dev-common package
> > or whether some more standard tool like pkg-config can be used instead.
>  Not an option here since the script does differ across architectures.

The discuss with upstream to create one script that handles multiple
architectures internally. Then the script would need to exist in the
native location and be called in that location with appropriate options
to detect the cross build.
>  The data will be different depending on the output of tcl's
>  configuration script, so it would be a maintenance nightmare to try to
>  maintain the output of the configuration script in a single tool
>  supporting all possible arches.

Some packages simply cannot be cross-built - dpkg-cross cannot have
special cases for every single one. Other packages with these problems
include ORBit, pango, GTK and anything using GObject marshalling.
>  The two ways I see this getting fixed:
> a) (preferred) get dpkg-cross to output a
>    /usr/share/arm-linux-gnueabi/tcl8.5/tclConfig.sh and change tcl-based
>    builds to look for that one when cross-building

Not going to be implemented.

> b) change tcl to output a tcl-cross-config-armel or similar package
>    containing just the above (very ugly IMHO); this would essentially be
>    like providing a cross-compiler except it's a cross-tcl-configuration
>    tool; it's very intrusive for the tcl packaging though

Carrying build meta data inside a package is dumb. It's one thing to
have libtool and Makefile hanging around in the source package, it's
quite another to package something like config.h in the binary -dev
package. That is what this -dev package is trying to do - include
buildd meta-data into a runtime -dev package. That data needs to come
from somewhere else, as with the pkg-config system, not from the -dev

>    @Neil: what would you think of providing some kind of extension
>  mechanism for these files in packages? 

The extension mechanism is called "patching the upstream source" and
has been used for a long time.

> e.g. dpkg-cross would run
>  /etc/dpkg-cross/hooks.d/*.pl and tcl8.5-dev would provide one, or
>  something similar?

Fix the package, not the build system.


Neil Williams

Attachment: pgpQmyaZUpmEw.pgp
Description: PGP signature

Reply to: