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

[Volker Grabsch]

Tony Theodore <address@hidden> schrieb:
> 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.

The Makefile modifies the environment only in two regards:

    1) add usr/bin/ to PATH
    2) unset trouble causing variables (CC, etc.)

However, the tutorial clearly states that both of these steps
should be done in the surrounding environment as well, especially
while working on a win32 port of some project.

So ideally there is _no_ such difference.

> I quite like the isolation of a temporary build environment that
> doesn't interfere with a normal profile.

I see it more as a "hack" or "bugfix" to the normal profile,
i.e. as something that shouldn't be really necessary in a
proper environment.

> > 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).

If some package really, really needed it, I'd add it to the
dependencies, hoping that most modern distros provide a package
for that. In case it is missing somewhere (e.g. OpenSolaris?)
I'd add build instructions to the "Requirements" section of the
docs.

I'd only add it directly to mingw-cross-env if there were too
many systems missing it. This has been the case for NSIS, and
for some irony, the fact that it is missing is directly correlated
to the lack of a MinGW cross compiler in a distro.

> 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.

I understand that problem, but I don't think we should solve
it in mingw-cross-env. Maybe a separate shell script for each
platform would be more appropriate. But currently, these "shell
scripts" are simple enough to be formulated in a "copy&paste howto"
- which is exactly what we currently have in the documentation's
"Requirements" section.

> 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.

This is an interesting use case. However, that screams even more
for platform specific shell scripts, possibly auto-generated from
the documentation. (or auto-interpreted from the docs)

The purpose of these buildbots is to check whether mingw-cross-env
runs under a certain system, not whether it runs on our own boot-
strapped system.

If one really wants a simple-to-bootstrap system, just use Debian.

    1) debootstrap
    2) chroot
    3) aptitude install ...
    4) hg clone ... mingw-cross-env
    5) cd mingw-cross-env && make

That's it.

> 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.

If the patch is so intrusive that you don't want it in your
normal path, what about naming it differently?

Also, it might be a good idea to use that "new make" only
where it is really needed, and not for all packages.

However, probably I'm totally wrong in that regard, because
I don't know exactly what they are patching and why.

> > 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.

No, the intention was to make the build process as transparent
as possible.

Maybe some target like "make run-shell" or even "make enter-PKG".
But currently, I don't really see a need for that.

> > 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.

I think there is a nice metaphor for that kind of mistake:

A long time ago, I wrote a GUI with many dialogs, where each
one showed a button to possible next dialogs. The dialog windows
were modal, and could be reoccurring later, in which case a second
dialog of that kind was created.

I tried to optimize that by loading with each dialog all potential
next dialogs. Of course, that lead to infinite recursion. I fixed
that by only loading the next dialogs when _showing_ the current
one. But what did that mean? It meant that with each dialog at
least one or two other dialogs are loaded. So in fact I didn't
optimize anything, I just made everything slower.

Note that my optimization would have worked if the navigation came
to an end, i.e. if there were finally dialogs that had no next
dialogs. However, such "end points" are exactly what the future
doesn't have.

So when writing for the future, one should concentrate on a specific
part of the narrow future. If one looks instead broadly into the
future at a certain depth, one always wastes a constant amount of
time.

> 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

Yes, please do that. I'm curious about that use case. :-)


Greets,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR