Re: DRAFT: Fixing the architecture query options of dpkg.
On Fri, Jan 08, 1999 at 11:34:18AM -0600, Manoj Srivastava wrote:
> Hi,
> >>"Marcus" == Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
>
> Marcus> I realized that it should be probably done without adding a
> Marcus> further binary, but directly in dpkg-buildpackage.
>
> I agree with most of the rest of your analysis, but I still
> would prefer to have this pulled out into a stand alone package, and
> merely have dpkg-buildpackage invoke it. That way we can even build
> the ability for calling individual targets out of the rules file even
> when cross compiling.
(Below I try to addresse your preferance. Please let me know if I
misunderstood it.)
The way I see it is the following: You want to cross compile. We want to
provide the cross compilation facility in a way that allows even multiple
build with different targets on the same machine. The only way I see is
using environment variables.
But, in that case, my proposal is sufficient, because dpkg-buildpackage
would just modify the environment variables, which you could also do by
hand. A script which makes it easier to modify the right variables to the
correct values sounds reasonable, though. Do you mean that?
Let me lay out three ways to do this, two of this I think come close to your
suggestion above (although I am not sure they really do).
My proposed way (just to recall it and so we can compare).
. using dpkg-buildpackage:
. Native compile: Use it just like you do now.
. Cross compile: Set the "-a" and "--target" option (or set env variables,
which will be honoured by dpkg-buildpackages).
. using debian/rules directly:
. Native compile: Use it just like you do now.
. Cross compile: Set the environment or use"VAR=value" feature of make
command line.
Variant I: a tool which can set env variables.
. using dpkg-buildpackage:
. Native Compilation: Use it just like you do now.
. Cross compilation: Set the "-a" and "--target" option, _or_ invoke the
new script manually with these options before you start the build
process, _or_ set the env variables manually.
. using debian/rules directly:
. Native compilation: Use it just like you do now.
. Cross compile: Run the script with "-a" and "-t" (or "-target") option
to set the environment variables. Then run it as you do now.
PRO: You only have to run the script once for several building steps.
CONTRA: You have to run it to return to "normal" operation", or to switch to
another target, as the environment is permanent.
Variant II: a tool which prints "VAR=value" options.
. using dpkg-buildpackage:
. Native compilation: Just like now.
. Cross compilation: Set the "-a" and "--target" option. dpkg-buildpackage
will invoke debian/rules this way:
`new-tool -a=${OPT_A} -t=${OPT_T}` debian/rules target
or this way:
debian/rules `new-tool -a=${OPT_A} -t=${OPT_T}` target
Another idea, which I like more:
Don't change dpkg-buildpackage at all, and start it with:
`new-tool -a=${OPT_A} -t=${OPT_T}` dpkg-buildpackage
. using debian/rules directly:
. Native compilation: Use it just like you do now.
. Cross compile: Do what dpkg-buildpackage does above, but manually.
PRO: Will not change the environment permanantly.
CONTRA: You have to remember to do it.
Comparing the three:
For native compilation, all ways to do it are equal, because new rules files
have backward compatibility build in if needed.
For cross compilation, all three are equal when using dpkg-buildpackage (the
latter two even work without modifying dpkg-buildpackage at all, if we want
so). Calling the debian/rules files directly, Variant I is preferable if you
do much compilations for one target, and Variant II is better if you change
the target arch often. Maybe both should be provided, which is not hard to
do anyway.
> I think that having a stand alne script that can be invoked at
> will is better than embedding it in dpkg-buildpackage. After all, I
> may need to know the GNU OS independently of building the whole
> package, in some script.
Sounds reasonable. The most important thing in my proposal was to strip the
call of the scripts from the rules file directly (modulo the backward
compatibility call to dpkg). Therefore, setting it in dpkg-buildpackage
appeared useful. If you now say dpkg-buildpackage should not make the
calculation, but get it elsewhere, this is fine. Note Variant II above: It
does not even require any manipulation of dpkg-builpackage. The "-a" and
"--target" option could be provided by the dpkg-buildpackage diversion in
dpkg-cross. If you want to cross compile just once, you could always call
the script manually, just as with the debian/rules method.
We should offer Variant I and II both in a single script. So people can
use Variant I if they do a lot of cross compilation, and Variant II if they
jump a lot between different targets.
Thanks,
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: