[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Separate build rules (was Re: [Mingw-cross-env-list] Mingw64)
From: |
Volker Grabsch |
Subject: |
Re: Separate build rules (was Re: [Mingw-cross-env-list] Mingw64) |
Date: |
Fri, 17 Sep 2010 13:10:15 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Tony Theodore <address@hidden> schrieb:
> On 27 August 2010 22:37, Volker Grabsch <address@hidden> wrote:
> >
> > We would the check which packages are suitable for that. I guess
> > that some packages would even need separate build rules to cross-
> > compile for a 64-bit platform.
>
> I'd be interested to know your thoughts on how this would be
> implemented. Would there be conditional PKG_BUILD rules or something
> like pkg.common.mk, pkg.target.mk, pkg-1-patch.target etc. ?
I thought that for the first step of simply using mingw-w64 to
build 32-bit-only, this wouldn't be necessary. It is important
to reach complete 32-bit support with mingw-w64 first, without
being distracted by 64-bit details that aren't relevant yet.
Having said that, here's my current plan.
(I'll introduce the new stuff in Mingw-cross-env and convert all
*.mk files if you really need that for your actual work now.)
First, we replace $(TARGET) with $(TARGETS):
TARGETS := i686-... x86_64-...
Then, each src/*.mk file contains multiple $(PKG)_BUILD rules:
define $(PKG)_BUILD_i686
...
endef
define $(PKG)_BUILD_x86_64
...
endef
By default, all 32-bit versions and all 64-bit versions of
all packages are built. They already have separate directories
(.../TARGET/lib/ etc), so the only danger is name clashing in
the .../bin/ directory, but that is already solved by our
requirement that everything in .../bin/ must have a prefix.
32-bit-only or 64-bit-only builds are possibile by adjusting
TARGETS accordingly, but that's optimization. By default we
simply build and test both, and everything runs fine.
The "install"-markers get a CPU suffix:
.../installed/mypackage
->
.../installed/mypackage_i686
.../installed/mypackage_x86_64
There might be other places to be adjusted, too.
Packages without 64-bit support have an empty BUILD_x86_64 rule.
Packages that have identical rules for 32/64 bit can be written as:
define $(PKG)_BUILD_i686
...
endef
define $(PKG)_BUILD_x86_64
$(mypackage_BUILD_i686)
endef
Note that you _can't_ use "$($(PKG)_BUILD_i686)" here yet. [1]
We could also introduce a special rule in the Makefile, such
that it tries $(PKG)_BUILD before trying specialized stuff.
That way, packages could simply write in the old syntax for
packages with identical build rules:
define $(PKG)_BUILD
...
endef
But I think the explicit approach mentioned above would be
cleaner.
Another possibility would be the introduction of conditionals
into the build rules, like this:
define $(PKG)_BUILD
... code for both ...
$(if $(filter i686-%, $(TARGET)),
# We might have to use $(3)
# instead of $(TARGET)
... code for 32-bit ...
,
... code for 64-bit ...
)
... code for both ...
endef
However, I doubt that this would increase readability. I think
it is really a good idea to keep and develop the build rules
separate from each other. It might be useful for cases where
the difference between 32-bit and 64-bit is just a minor tweak,
though.
I more critical point are the dependencies. I thougt about
having separate dependencies for each package:
$(PKG)_DEPS_i686 := ...
$(PKG)_DEPS_x86_64 := ...
However, I guess this _wouldn't_ be a good idea. Since we
use empty build rules for unsupported packages, mentioning
them in the DEPS doesn't do any harm. That's why we can
simply keep a complete list of dependencies for each package.
I also thought about the possibility of having separate files
for each package, which would allow for separate versions and
dependencies for the 32/64-bit version of each package. However,
this would effectively double that effort needed to keep
Mingw-cross-env up to date. A similar issue arose with the
static/shared variants which is why we stick with one of them.
So our goal should be to keep the 32/64-bit versions as
closely together as possible, using the same versions
with the same dependencies and the same set of patches.
(Patches should contain only compatibility stuff anyway.)
> I've been trying to figure out a way of running the multiple
> scenarios (and multilib in the future) but can't see how
> without some ./configure like steps.
Don't waste too much time on that. It is perfectly okay to
build Binutils and GCC twice - once for 32-bit and once for
64-bit, as we do for all other packages, too.
In the end of the day, we need separate binaries such as
i686-*-gcc / x86_64-*-gcc anyway. So a multilib build would
actually _complicate_ things for us.
The only downside is this this would increase the build time.
But I'm happy to trade that for additional stability. We do
similar trade-offs in other corner of Mingw-cross-env. Also
note that GCC doesn't take that long compared to other packages
like Qt, and duplicate build time of those big libraries can't
really be shortened.
Greets,
Volker
[1] This is because that term would have to be evaluated partly
"immediate" and partly "deferred", which is AFAIK not supported
by Make.
So we would have to rewrite all $(PKG)_BUILD rules in a way
that they have to be evaluated twice, i.e. replacing all $(1)
to $$(1) and having to quote $ in shell commands not only as
$$ but as $$$$. This would be another source of mistakes that
are hard to debug, which isn't worth the trouble.
However, it might be a good idea to somehow get $(PKG) up
to date. Then we might even be able to replace $(1) and $(2)
with something like $(BUILD_DIR) and $(TEST_PREFIX). I'll
have to think more about it, maybe there's an easy way to
achieve that.
--
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR