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

[Volker Grabsch]

Tony Theodore schrieb:
> On 19 December 2010 03:16, Tony Theodore <address@hidden> wrote:
> 
> > Having said that, I thought I'd go ahead with a proof-of-concept,
> > changesets attached.
> 
> I've progressed to building all of mingw-cross-env using the mingw.org
> runtime, and qt using mingw-w64. I've set up a repository here:
> 
> https://bitbucket.org/tonyt/mce-multi-target/

Thanks for your work. As soon as I find some time, I'll try to
provide the necessary infrastructure in mingw-cross-env, possibly
inspired by your fork.

The idea is that in the near future, the fork will only differ
from the main project by some additional *_BUILD_x86_64 sections.

BTW, I'm also planing to clean up the download code in the main
Makefile, as this also has some flaws.

> Everything seems to be working correctly, with a couple of observations.
> 
> 1. Build order can be a little confusing. It initially looks like it's
> building i686 targets, then switches to x86_64 after the first
> specified package is reached. If you're calling "make package" this is
> all fine, but a plain "make" will build atk_i686 and all i686 deps,
> then switch.

I think you can influence this by the order in which the macros
generate the build rules, i.e. the order of the foreach loops.

> 3. There's lot's of flexibility with consolidating common build
> sections. freetds, openssl, and qt are examples of "good?" style, gcc
> probably isn't. We'd want to establish some conventions around this as
> you can do some elaborate and complex things.

Feel free to provide any coding style improvements directly to
mingw-cross-env. In general, I think it's a good idea for a fork
not to drift apart too much.

> 4. Still need to decide what to do with "empty" build rules, and
> possibly find a way of distinguishing between a know failure and
> package that simply downloads a tarball.

I think this should be done by not providing those build rules
at all. That is, and empty build rule means it is a download
package. A missing build rule (*_BUILD_x86_64 not defined) means
that the package is not (yet?) supported for 64-bit systems.

The only remaining question is what to do with packages that are
by design 32-bit only (or 64-bit only, for that matter). An empty
build rule would mean those are download-only packages, which would
simply be wrong: Their downloads aren't useful at all for the other
platform. In other hand, providing no build rule might suggest those
would become available for the 64-bit platform in the near future.
At the moment I think the latter is the lesser evil. There's nothing
wrong with stating e.g. that the GCC package in unavailable for
the 64-bit platform as well as stating that the mingw-w64 package
is unvailable for the 32-bit platform. However, I'm open to better
suggestions as long at those don't complicate things.

> At some stage, we might want
> to parse the src/*.mk files and update the package list in the docs
> with their 64-bit support.

That's a good idea. I think we should simply add one column for
each architecture (i686, x86_64), stating whether this is supported
or not.


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---