Hello William,
William schrieb:
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!
Thanks for summarizing! In particular, thanks for making
your concept "SRC vs TARGET" more clear. I didn't get
that in the first place. (I still prefer the one-srcdir
approach, but for different reasons. See below.)
Before digging into the details, just a small clarification:
I'd love to see your MinGW-w64 work included in this project,
regardless of how we design the multi-target approach. Note
that I don't expect you to implement the multi-target framework
(Maybe my first reply sounded like that, but that was not my
intention!) If there's anything preventing you from pushing
your changes into the multi-target framework, feel free to push
it as a fork on GitHub and to ask others to do the integration.
That would be perfectly fine, as you already did the hard work
of tweaking and testing. However, I'd be happier if I could
convince you to incorporate your changes directly into the new
framework. ;-)
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...
I agree that we should be able to loosen those constraints
for specific "bad" packages (see Point 1.3).
However, I think it is very important to have a simple
(comfortable) way to port fixes for one target to another
target. Or even better: To fix issues for all targets at
once in the first place. For most packages this is
certainly possible, so we should design for that, rather
than treating the many "good" packages like an exception.
Having a fork (or branch) for each new target is already
possible, and fixes are easily transferred via merge
(or rebase). If our multi-target approach isn't any better
than that, there's no reason to implement it, as it wouldn't
be any improvement to the current situation.
That's why I don't like having separate files or directories
for each target. I want multiple targets to share as much
code as possible.
You are already proposing that the two mingw-w64 variants
"32-bit" and "64-bit" share the same code. However, I don't
think we should decide upfront which targets should and
should not share code. I'd love to handle this on per-package
basis, where:
- Most packages use the same build code for all toolchains,
with a small conditional about static/dynamic builds.
- Some packages need separate build code for static/dynamic
builds, but it's the same code for all toolchains.
- Some packages need separate build code for MinGW and MacOSX
targets, but can handle static/dynamic builds with the
same code.
- Some packages need separate build code for 32-bit / 64-bit.
- Some pacakges are 32-bit only.
and so on. In other words: Of course some packages may have
to diverge between targets, but I'd like to write this
extra code only when needed.
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.
I agree that enforcing the same version of each package
would be too hard.
For pathological cases, we'll have to provide the possibility
to use per-target versions. This could be handled via
a separate package file, or via some variable suffix like
$($(PKG)_VERSION_i686_dynamic_mingw32).
However, I don't think this will become the norm, or that
we should even encourage this. We aren't Debian or Fedora!
We're in the lucky position to not have to QA every package
upgrade. We just upgrade the packages' versions (in a mostly
automatic fashion), check if they build on all targets
(i.e., run "make"), and it's fine!
That's how we're already operating right now. Sometimes packages
are upgraded just because a new version is out, by someone
who isn't actually using it! Not because the new version is
needed, but because it's available and because everything
still builds fine after upgrading.
I think we can transfer this workflow directly to the
multi-target approach. You need a new version? Just upgrade
it for all targets, as long as it compiles. If this causes
issues on some target, that needs to be addressed afterwards.
Nobody will get upset on you. No need to be overy carefully
here. In fact, that's what the development branch is for!
In the rare case that your upgrade makes the build fail
on one specific target (but no other), there are enough
people here to help out. In the worst case, we should have
some last-resort mechanism to downgrade the package for a
specific target (see above), but we shouldn't optimize
for those cases, let alone encourage varying per-target-
versions by design.
Also, if some package fails on a platform and nobody
(including upstream) cares about it, maybe it's even
better to remove it for that target.
But my point is: No matter what solution we'll take,
this should affect only the single "bad" packages, not
the overall design and the overall workflow. We should
optimize our workflow towards those packages which work
"with us" rather than those packages which work "against us".
[ I removed Point 2, because I already replied to the
clarification about SRC/TARGET in Point 1. ]
[ I removed Point 3, as it has already been clarified by Tony. ]
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.
When I wrote that code (years ago), I did that for the simple
reason that I wanted "make clean" to remove the installed/
folder, but to not remove the logs. So out of pure laziness,
I put installed/ into usr/, so it would be automatically cleaned up.
Today, I think that keeping logs doesn't make sense after
"make clean" (and if you really need them, you can still copy
them before running "make clean"). Rather, I find it more handy
to have all generated stuff in one directory: usr/. I also find
it more handy to have only the relevant logs (everything after
the last "make clean") available, when especially when analyzing
some build issues or bugs.
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.
That's another issue. However, note that this mechanism
does not only take care of usr/, but also of pkg/, log/,
dist/ and the tmp-*/ directories. All those are created
relative to the current directory, while src/ and doc/
are always taken relative to the main Makefile.
[ I removed Point 5, because it is irrelevant to this discussion. ]
[ I removed Point 6, because there were no objections. ]
Regards,
Volker