mingw-cross-env-list
[Top][All Lists]
Advanced

[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
---<<(())>>---



reply via email to

[Prev in Thread] Current Thread [Next in Thread]