> > Currently the binary archives from mingw.org and the automated builds
from this project that I use put their artifacts in the top level of the
archive, while the rubenvb builds place their artifacts in an intermediate
'mingw32' directory.
> >
> > This difference complicates some of my current automated build juju, and
I don't want to change my stuff :P
> >
> > Ruben...assuming this minimally tested patch works and doesn't break
your build process, can I cajole you into accepting and changing your future
releases?
> >
>
> Can you give more background information? How does an extra directory
> affect your builds?

As part of an automated build, I assemble various MSYS and MinGW parts into
a whole having a final a structure similar to:

C:\DevKit-w64  <- extract all MSYS-y things under here
 |- bin/
 |- etc/
 |- ...
 |- mingw/     <- extract all MinGW-y things under here
    |- bin/
    |- i686-w64-mingw32/
    |- mingw/
        |- bin/
        |- include/
        |- lib/
        |- lib32/

Currently my process simply extracts everything mingw-y under the
first-level mingw/ so that I don't need to play with /etc/fstab. I also
include a devkitvars.{bat,ps1} that allows a user to add
C:\DevKit-w64\bin;C:\DevKit-w64\mingw\bin to the front of their PATH.

The mingw32 dir at the top-level of the current rubenvb builds (aka -
intermediate mingw2) causes issues with the above.


> If you are referring to the lower mingw32 directory, it is needed gcc
> internally, that is the sysroot equivalent of /usr/, Linux has /usr,
> mingw has /mingw32. So best to leave it alone.

No, no...definitely not talking about the lower mingw32 dirs.


Jon

---
blog: http://jonforums.github.com/
twitter: @jonforums

Most people die of a sort of creeping common sense, and discover when it
is too late that the only things one never regrets are one's mistakes.
                                                           - Oscar Wilde
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to