Re: [Mingw-cross-env-list] mingw-w64 and mingw-cross-env

[William]

Dear all,

I spent time making a sumary of the discussions. I hope it will help! 
Points go from 1 to 6. My purpose in all this is to produce a working 
and integrated mingw-w64 architecture in mingw-cross-env, in order to 
push my local work, without having to do this in an other project!

Regards,
Wiliam


Point 1 : make one unique directory (a) for *.mk files, or let them have 
their lives in different source directories (b)

1.1)  in discussion :
[Volker Grabsch] solution (a) better : Well, the original plan (on which 
I'm currently working) is
to provide a structure which encourages us to keep the targets
in sync. 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.
[William] Is it so important to have exact matching versions of 
packages? maybe not...

1.2) for (a)
[Volker] 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.

1.3) in discussion
[Volker] constraint : All targets will use the same version (the same 
source tarball) of a package
[Volker] this is more a strength, I think, as we won't
have to maintain multiple versions of each single package.
[LM] likes this approach
[William] This is a big point. I think enforcing the same version will 
make the community stop providing version patches. A contributor working 
on target "x86_64-w64-mingw32" (mingw-w64 64 bits) would never try to 
commit an upgrade in package version, because he would not known if this 
would suit other targets, and he would have no motivation to install an 
environment to test it. As contributors are lazy or selfish ;-), They 
would be more likely to keep the changes locally! On the contrary, 
having separate directories would make it easier for contributors to 
patch versions of packages. Moreover, it would be easy to take examples 
from more advanced packages from other targets.

1.4) in discussion
[Volker] constraint : All target will have the same set of dependencies 
$(PKG)_DEPS.
[Volker] 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.
[LM] I keep thinking it is going to be an issue. There are times when 
building for one system requires completely different dependencies than 
building for another. If the dependency isn't available for the target, 
you've indicated there isn't a problem. However, what if a dependency is 
available, but not desired in that platform specific build? It may not 
be an issue with limited targets, but if number of targets grows, so 
does the possibility of this happening. I wish I could think of some 
concrete examples, but I'm coming up blank at the moment.
[Volker] I doubt there will ever be such an example, because if a 
library has different dependencies on different platforms, its author 
will certainly add some platform conditional code into configure.ac (or 
similar). That is, maybe an unneeded depdency gets built, but it almost 
certainly won't cause an build issue in the library itself. Otherwise 
it's a bug in the library that needs to be fixed. However, if we should 
really encounter such a rare example, we could add support for 
target-specific $(PKG)_DEPS, too. This should be optional, though, as 
almost all packages won't need that feature.





Point 2 : mingw-w64 targets
[William] :
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)

[Volker] :
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?

[Luis Saavedra]
completely agree! [with Volker]

[William]
Just a point on mingw-w64 :
mingw-w64, when not "multilib", can be built with two triplets :
- either i686-w64-mingw32 for 32 bits executables
- either x86_64-w64-mingw32 for 64 bits executables.
Now, if you have something that works with the "x86_64-w64-mingw32" 
target, then to build 32 bits targets is as easy as replacing 
"x86_64-w64-mingw32" by "i686-w64-mingw32" in the mingw-cross-env TARGET 
value in the Makefile. If you make patches for mingw-w64 that work, then 
it will work for 32 bits as well. With the mingw-cross-env framework I 
proposed, I introduced a new environment value: SRC, to specify which 
branch of *.mk files to use. This works along with the already working 
TARGET value. For example, in my local mingw-cross-env I can :
- build on mingw.org, with TARGET = i686-pc-mingw32 and SRC = mingw 
(mingw is the new name for the actual src/ directory)
- build on mingw-w64 32 bits with TARGET = i686-w64-mingw32 and SRC = 
mingw-w64 (my local, and not commited, mingw-w64 branch)
- build on mingw-w64 64 bits with TARGET = x86_64-w64-mingw32 and SRC = 
mingw-w64 (my local directory, the same for both 32 and 64 bits targets)




Point 3 :
[Volker] :
> Also, I'd like to "misuse" the already misused VENDOR
> part (*-pc-*) in a different way:
>
> i686-static-*
> i686-dynamic-*
>
> I guess that "static" and "shared" are easily confused
> on a quick read, so it might be better to use "dynamic"
> rather than "shared".
>
> I also wonder if the suffix "mingw32" is really a sensible
> thing for a 64-bit architecture. I guess this is because
> some ./configure scripts are still checking for *-mingw32
> rather than *-mingw*, but on the other hand, this is easily
> fixed with a platform-indepdent patch.
>
> Regarding the Mac platforms, we might use the same schema,
> using "*-static-*" instead of "*-apple-*", as the configure
> scripts usually check for the "darwin9" suffix and not for
> the "-apple-" part.
>
> So all in all, I'm proposing the following target names:
>
> i686-static-mingw
> i686-dynamic-mingw
> x86_64-static-mingw
> i86_64-dynamic-mingw
> x86_64-static-darwin9
> x86_64-dynamic-darwin9
>
> (and maybe ppc-static/shared-darwin9 for very old Macs.)
>
> @all: What do you think about it?

[LM]
If you're using this on the configure command line (like most Slackware 
packages do), this could be a problem. Most configure scripts wouldn't 
recognize these targets and would probably require modifications. If 
this is only used in the file structure and not sent to configure, it 
should work okay.

[Volker]
Those target names are indeed meant to be used as ./configure arguments, 
not just for the file structure. You are absolutely right that we should 
make a real test run to check that the new target names won't cause any 
issues. I didn't ever see a build script which checks for the VENDOR 
part of the target. However, some helper scripts like config.guess might 
have trouble with "mingw" instead of "mingw32", or with the pseudo 
vendor string (static/dynamic). Also, what's with Qt/QMake and with 
CMake? We should really check that. On the other hand, what are the 
alternatives? I believe that a TARGET like "i686-static-mingw" will 
cause less trouble than, say, something like "i686-pc-mingw32static". 
Any ideas? Any volunteers to make test builds with the new TARGET strings?

[Tony]
binutils doesn't recognise mingw, so we may have to stick with mingw32.
qmake.conf references i686-pc-mingw32 specifically, but its really just 
to find prefixed executables and should be easy to replace inline. The 
CMake toolchain file should be fine, but will need to be created in a 
target specific location in the future.
I really like the idea of re-purposing the VENDOR part, it's hard to 
imagine that anything would actually change behaviour based on "-pc-", 
the only real issue can be that anything else is unrecognised.
I'll run a few different strings and see what happens.

[William]
It is to my point of view hard (impossible?) to change vendors names.
However, I would still propose the use of a SRC value in the Makefile, 
along with the TARGET value. The TARGET value is the vendor triplet, 
while the SRC value specifies the branch of *.mk files to use (either in 
different directories, or in a unique directory, cf point 1)
i686-static-mingw      -> TARGET=i686-pc-mingw32, SRC=mingw-static
i686-dynamic-mingw -> TARGET=i686-pc-mingtw32, SRC=mingw-dynamic
x86_64-static-mingw -> TARGET=x86_64-w64-mingw32, SRC=mingw-w64-static
x86_64-dynamic-mingw -> TARGET=x86_64-w64-mingw32, SRC=mingw-w64-dynamic
x86_64-static-darwin9 -> TARGET=x86_64-w64-mingw32, 
SRC=mingw-w64-static-darwin
x86_64-dynamic-darwin9 -> TARGET=x86_64-w64-mingw32, 
SRC=mingw-w64-static-darwin
And I would also add (for mingw-w64 32 bits static) :
TARGET=i686-w64-mingw32, SRC=mingw-w64-static (SRC is the same as for 
the "x86_64-static-mingw")




Point 4 : structure for multitarget approach

[william]
> > > The changes I made :
> > > - slightly modified Makefile, with a "SRC" parameter added (for
> > > either mingw or mingw-w64 source directory)
> > > - move "src/*.mk" files to "src/mingw/*.mk" files
> > > - the process changes log files to produce, instead of "log/*" :
> > > log/i686-pc-mingw32/*
> > > log/i686-w64-mingw32/*
> > > log/x86_64-w64-mingw32/*
> > > - the process changes "usr/installed/*" files to :
> > > usr/installed/i686-pc-mingw32/*
> > > usr/installed/i686-w64-mingw32/*
> > > usr/installed/x86_64-w64-mingw32/*

[Volker]
> 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?

[Luis]
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),

[William]
My proposal looks more like Luis's, for the same reason (separate 
toolchain and mingw-cross-env own production). However,
for the "installed" directory, it seems that it was put in the /usr 
directory for some reason. I saw it is possible to run mingw-cross-env 
Make from a different directory. In that case, it is important to have 
the "installed" directory stay inside the "usr" one.





Point 5 :
[Luis Saavedra]
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.


Point 6 :
[William]
It seems that every body agrees on the unique set of patches approach