Hello William,
Thanks for your work, and for offering your patches!
Unfortunately, we can't take those as-is.
I guess you were missing some discussions around that
topic. But maybe that was my fault, because I'm not
sure whether all those discussions happened on-list.
hello all,
I think it's time to create an experimental branch on github, bitbucket or savannah, like bitbucket.org_mce-multi-target_tony experiment (which is outdated), in my experimental branch bitbucket.org_mce-msys I have compile everything except exiv2, nsis, sdl_mixer, t4k_common and vmime, but I think that mce-msys is in the case of another version, msys is not a mature system nor unix, anyway: please accept some patches about it.
On major point was to not let the various versions
diverge too much from each other.
William schrieb:
> On 03/18/2012 01:38 PM, William wrote:
> >Tony identified 3 points (see above). I spent quite some time
> >thinking all this.
> >
> >1 : "overhead of multiple runtimes, supporting both
mingw.org and
> >mingw-w64". It is true that including mingw-w64 support in
> >mingw-cross-env will increase the work!
Well, it inevitably does increase the initial work, but in the
long run, we'll hopefully be able to maintain an n-target system
with less than n-times the amount of work.
> >No way to find a smart
> >solution that solves this. However, the community will also get
> >bigger! And ultimately, you can hope that the mingw runtime will
> >get deprecated, and then focus on mingw-w64.
Our plans are to support multiple targets in the long run,
not just in the short run. For instance, there will also
be separate toolchains for mostly-static and mostly-shared
builds of the libraries. Also there are plans to include
cross-compiling support for MacOS-X (at least for a subset
of our packages).
> >3 : simplicity and coherence of design in mingw-cross-env
> >That is the big point. The solution that Tony created was
> >modifying every *.mk files to include support for both mingw and
> >mingw-w64. I propose something different.
> >- two parallel source directories, instead of one : mingw with its
> >*.mk files, and mingw-w64 with its own *.mk files.
Well, the original plan (on which I'm currently working) is
to provide a structure which encourages us to keep the targets
in sync. Moreover, for most packages, all build sections would
be identical, i.e.:
define $(PKG)_BUILD_aaa
...
endef
$(PKG)_BUILD_bbb = $(PKG)_BUILD_aaa
$(PKG)_BUILD_ccc = $(PKG)_BUILD_aaa
...
In the worst case, there is a separate code for each target. But
even then, if you fix one target, this structure would encourage
you to fix the other targets, too. Having separate packages would
require more discipline to not let them diverge.
Of course, this structure does impose some constraints, which
are not present in the multiple-srcdir approach:
1) All targets will use the same version (the same source tarball)
of a package.
2) All target will have the same set of dependencies $(PKG)_DEPS.
3) The patches will be used by all targets, there are no
target-specific patches.
Regarding 1), this is more a strength, I think, as we won't
have to maintain multiple versions of each single package.
Regarding 2), this is no problem. Only those dependencies
that are actually available for that target will be built.
The other dependencies are ignored for that target. That
way, we can simply keep the $(PKG)_DEPS list "full featured",
and won't have to maintain separate dependency lists for
every target.
Regarding 3), this will enforce cleaner patches, which have
a better chance of being accepted upstream. However, maybe
this constraint is too hard for some packages - some might
just require nasty target-specific patches. In that case,
we could easily add support for target-specific patches.
(BTW, the patches system might have to be revised anyway,
using Mark's patch<->git tool (tools/patch-tool-mingw)
more consequently for all packages. Then, we'd have just
one patch file for every package, making it even more
straight-forward to define how target-specific patches
have to be named -- either as multiple patch files, or
as separate branches within the ad-hoc git repository.)
> >2: "mingw-w64 preference for multilib". Actually, this is not
> >really true. Mingw-w64 proposes 2 way of building it :
> >- either you do "multilib"
> >- or you compile first for 64 bits, then for 32 bits.
> >But the community prefer using the second solution. It is easier
> >to handle (I discussed this point on the mingw-w64 forum) when
> >building tools on top of gcc.
I fully agree that multilib is the wrong approach for
mingw-cross-env, and that multi-target is the way to
go, as it is more flexible and less confusing.
This is especially true when we'll have separate targets
for mostly-static and mostly-shared builds. Those work
only well when the toolchains are strictly separated.
Otherwise we'll have to deal with lots of bugs of packages
that link to DLLs but are meant to be statically linked,
or vice versa.
The only downside of the multi-target approach is the
increased disk usage, but I'm happy to trade this against
avoiding lots of hassle. Also, users who build just one
target are even saving some disk space compared to the
multilib approach. ;-)
> >- three possible targets : i686-pc-mingw32 (works with mingw) ,
> >i686-w64-mingw32 (works with mingw-w64, for 32 bits),
> >x86_64-w64-mingw32 (works with mingw-w64, for 64 bits)
Do we really need i686-pc-mingw32 as well as i686-w64-mingw32?
Why not simply using i686-pc-mingw32 as is, and switch that
to 32-bit MinGW-w64 as soon as all packages work with it?
Is there any advantage in providing (and maintaining) two
32-bit static-lib toolchains that have different names?
completely agree!
...
Those are all sensible changes, although I wonder if we're
able to produce something more coherent. If we're changing,
anyway ...
Since we already have this:
usr/i686-pc-mingw32/bin/
usr/i686-pc-mingw32/include/
usr/i686-pc-mingw32/lib/
We might want to add this:
usr/i686-pc-mingw32/installed/
usr/i686-pc-mingw32/log/
The only issue here is that "make clean" has to be
more careful to not destroy old logs. So maybe
the separate place "log/" does have some justification.
On the other hand, logs are quite big and accumulate
quickly, so maybe it's actually a good thing if
"make clean" cleans up the logs, too.
@all: What do you think?
I think it should be something like
usr/i686-pc-mingw32/bin/
usr/i686-pc-mingw32/include/
usr/i686-pc-mingw32/lib/
log/i686-pc-mingw32/
installed/i686-pc-mingw32/
because log and installed are of a different nature (not part of the toolchain, but part of mingw-cross-env),
regards,
Luis