[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mingw-cross-env-list] Variable JOBS
From: |
Volker Grabsch |
Subject: |
Re: [Mingw-cross-env-list] Variable JOBS |
Date: |
Thu, 3 May 2012 23:29:02 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Moritz Bunkus schrieb:
> I don't want to put something as generic as JOBS into my environment.
> I also don't really want to pollute each and every shell's environment
> with mxe-specific stuff (I also overwrite the download mirror).
>
> Reading a local Makefile (e.g. "Makefile.local") if it exists would
> actually allow us to do more than just specifying the amount of jobs
> to build in parallel. For example, I'd like to define a target that
> depends on the packages I usually build for my application so that I
> don't have to look up that list every time I clean mxe.
A similar idea has been in my head, too, for some time. However,
I thought of it more as a settings file, and I'd recommend to
not add any make target, but to just override some variables.
For instance, if you overwrite $(PKGS) instead of defining your
own make target, you get some interesting benefits: "make" builds
only your packages, "make download" downloads only your
packages (and their dependencies), "make update" checks only
for updates of your packages. And so on.
That's why I prefer to think about it more as a configuration /
settings file instead of a Makefile. But that's a matter of
taste. There is no reason to put any restrictions on the
settings file. I you really need to add a make target, you
should be able to just do so.
I'd like to use that mainly for setting $(JOBS), $(PKGS), and
for $(TARGETS) in the future, as it doesn't make sense to
build all cross toolchains for all supported targets.
Well, with one exception: Our testing phases should still
try to build as much as possible. So it makes sense to
provide a variable which always disables the inclusion:
make clean
make IGNORE_SETTINGS=yes
so that everything is built nevertheless.
Also, it may make sense to disable some toolchains by
default. For instance, a (to-be-created) Mac toolchain
will almost certainly require the MacOSX SDK, which is
not freely downloadable (it requires a registration,
which doesn't cost money, though), and whose free
distribution is prohibited by Apple's license terms, as
far as I know. So enabling Mac support by default would
encouraging every MXE user to register on Apple, which
is certainly not what we want. ;-)
Finally, I think that the settings.mk should be created
automatically if it doesn't exist, with some hints about
what you might want to configure.
I just added a first implementation of that feature to
the master branch. Feel free to play around with it,
and to check if that fits your need:
https://github.com/mxe/mxe/commit/6f47641
Regards,
Volker
--
Volker Grabsch
---<<(())>>---
- Re: [Mingw-cross-env-list] Variable JOBS, (continued)
- Re: [Mingw-cross-env-list] Variable JOBS, Daniel Stonier, 2012/05/02
- Re: [Mingw-cross-env-list] Variable JOBS, Moritz Bunkus, 2012/05/02
- Re: [Mingw-cross-env-list] Variable JOBS, Tony Theodore, 2012/05/02
- Re: [Mingw-cross-env-list] Variable JOBS, Moritz Bunkus, 2012/05/02
- [Mingw-cross-env-list] Sourceforge Mirror (was: Variable JOBS), Tony Theodore, 2012/05/02
- Re: [Mingw-cross-env-list] Sourceforge Mirror (was: Variable JOBS), Volker Grabsch, 2012/05/03
- [Mingw-cross-env-list] Custom package configuration (was: Variable JOBS), Nikos Chantziaras, 2012/05/03
- Re: [Mingw-cross-env-list] Variable JOBS, Moritz Bunkus, 2012/05/09
- Re: [Mingw-cross-env-list] Variable JOBS, Volker Grabsch, 2012/05/10
- Re: [Mingw-cross-env-list] Variable JOBS, Moritz Bunkus, 2012/05/20
- Re: [Mingw-cross-env-list] Variable JOBS,
Volker Grabsch <=
- Re: [Mingw-cross-env-list] Variable JOBS, Moritz Bunkus, 2012/05/08
- Re: [Mingw-cross-env-list] Variable JOBS, Volker Grabsch, 2012/05/08
- Re: [Mingw-cross-env-list] Variable JOBS, Moritz Bunkus, 2012/05/08
- Re: [Mingw-cross-env-list] Variable JOBS, Tony Theodore, 2012/05/08