[Mingw-cross-env-list] Makefile environment variables (was Combining 32-bit and 64-bit support)

[Tony Theodore]

On 21 April 2010 02:29, Volker Grabsch <address@hidden> wrote:
> Tony Theodore <address@hidden> schrieb:
[...]
>> I was also experimenting installing flex and other build time
>> requirements in usr/local and adding that to the PATH only in the
>> Makefile.
>
> Oh, I don't think this is a good idea. It was always very helpful
> for debugging that one could execute the build commands of the
> src/*.mk directly at the command line (except for trivial place
> holders such as "$(TARGET)").

It is very helpful to be able to do that while debugging, but the
Makefile already modifies the environment so it isn't always possible.
I quite like the isolation of a temporary build environment that
doesn't interfere with a normal profile.

> Also, why should we use a different Flex than the one of the
> operating system? That might lead to a lot of confusion.

Flex may not be the best example, xz may be better. You don't really
want to add it to the requirements, but it would be trivial to build
in case some package needed it (say xine-lib). This means duplicating
the os packaging system to an extent, but some systems (opensolaris)
are pretty weak in that regard, and it often seems like it would be
simpler to bootstrap more of the requirements. Macports is another
example - you install scons and end up with a whole range of X11
libraries because the python package installs tk by default.

Those aren't real problems though, the current guidelines strike a
good balance between stable requirements and not having to maintain
too much. I've been playing with setting up a buildbot and thinking
that a more self-contained build environment is better. I noticed that
there is a patched make in mingw-w64 - if it turns out to be
necessary, I'd rather not have it on my normal path, but still be
available to the build process.

> I generally don't like the idea that a "$(MAKE)" during "make zlib"
> might produce different results than calling it by hand, outside
> the mingw-cross-env Makefile ("cd tmp-zlib/zlib-1.2.5/ ; make").

I thought that was specifically the intention - the Makefile *should*
produce a different result unless you set a up an interactive profile
that mimics it.

> Sorry for stopping you on that, but I fear that this might go
> into a horribly bad direction.

I appreciate your comments, you've saved me lots of wasted time
before. I think I'm just pre-empting solutions to problems that don't
exist yet.

There is one concrete use of usr/local (or a temp install dir) in the
native build of libiconv for glib on OSX using the default gcc42. I'll
put it in a separate mail after I've had a chance to look into it
further - the current workaround of using gcc40 is fine in the mean
time.

Cheers,

Tony