On Thu, Jan 07, 1999 at 07:40:42PM +0100, Marcus Brinkmann wrote: > Using a seperate tool for this has several advantages, as long as this tools > is > added to dpkg-dev and we can use it in the rules files (so this additional > tool should be required, and not optional, for package building purpose).
Sorry to follow up on my own message, but something important occured to me. I realized that it should be probably done without adding a further binary, but directly in dpkg-buildpackage. WRT to the target arch query options, I realized that there needs to exist some way to tell the supporting script which architecture is used in this special build. The only reasonable and obvious way seems to be by passing environment variables to the rules file. But then, when we use environment variables, why not providing the architecture strings directly? This way, we would not have additional burden of calling executables or scripts in the rules files. Additionally, the way to obtaion these values is not hardcoded in the rules file, but wrapped inside dpkg-buildpackage (much nicer, IMHO). dpkg does not need to be changed at all (only if we _want_ to have gnu-build-os at the same place as gnu-build-target, or we should reimplement both and don't use dpkg for these at all). So, dpkg-buildpackage would call "make debian/whatever" with following environments: DEB_BUILD_ARCH DEB_TARGET_ARCH DEB_BUILD_GNU_ARCH DEB_BUILD_GNU_OS DEB_BUILD_GNU_SYSTEM=$(DEB_BUILD_GNU_ARCH)-$(DEB_BUILD_GNU_OS) DEB_TARGET_GNU_ARCH DEB_TARGET_GNU_OS DEB_TARGET_GNU_SYSTEM=$(DEB_TARGET_GNU_ARCH)-$(DEB_TARGET_GNU_OS) The default values would be: DEB_BUILD_ARCH='dpkg --print-architecture' DEB_TARGET_ARCH=$(DEB_BUILD_ARCH) DEB_BUILD_GNU_ARCH='dpkg --print-gnu-build-architecture' # or an equivalent reimplementation DEB_BUILD_GNU_OS='dpkg --print-gnu-os-architecture' # or implemented directly in dpkg-buildpackage DEB_BUILD_GNU_SYSTEM see above DEB_TARGET_GNU_ARCH=$(DEB_BUILD_GNU_ARCH) DEB_TARGET_GNU_OS=$(DEB_BUILD_GNU_OS) DEB_TARGET_GNU_SYSTEM see above All existing scripts would continue to behave just like ever. All new scripts could/should have this lines or a subset of used variables to fall back to the default behaviour if an old version of dpkg-dev is used: DEB_BUILD_ARCH='dpkg --print-architecture' DEB_TARGET_ARCH=$(DEB_BUILD_ARCH) DEB_BUILD_GNU_ARCH='dpkg --print-gnu-build-architecture' DEB_BUILD_GNU_OS=linux DEB_BUILD_GNU_SYSTEM see above DEB_TARGET_GNU_ARCH=$(DEB_BUILD_GNU_ARCH) DEB_TARGET_GNU_OS=$(DEB_BUILD_GNU_OS) DEB_TARGET_GNU_SYSTEM see above This would maintain full backward compatibility! dpkg-buildpackage would accept two options, for example "-a" and "--target", to set DEB_TARGET_ARCH and DEB_TARGET_GNU_SYSTEM for cross compilation (where DEB_TARGET_GNU_ARCH/OS would be determined from the letter automatically). For example, to cross compile a package for the Hurd: dpkg-buildpackage -ahurd-i386 --target=i386-gnu -B The only drawback I can see: If you do cross compilation, you can't easily run "debian/rules target" and expect it to work. You'd need to set the variables correctly. However, this is a small price and does only affect cross compilation. Currently, cross compilation is not supported at all (without major hacks and dpkg-cross), so this is not a big deal. (This is a direct consequence from the fact that we don't have a debian/configure, similar to GNU configure. GNU configure does not have the problem, because it builds the Makefiles before using them. In our case, a default of native compilation is hard coded in the rules files, for backward compatibility). Are there other drawbacks? Currently I think this is the best option. I will be back tomorrow night, and try to implement and test this. Thanks, Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@ Marcus Brinkmann http://www.debian.org master.debian.org [EMAIL PROTECTED] for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
