On Wed, 6 Oct 2010 13:22:08 +0200 Loïc Minier <loic.min...@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 cross-architecture? > 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 package. > @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 ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
pgpCgJjaDclxb.pgp
Description: PGP signature
