Re: Separate build rules (was Re: [Mingw-cross-env-list] Mingw64)

[Volker Grabsch]

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