New packages

[Charles Wilson-8]

I'm gearing up to refresh some of the packages I've created in the past
for mingw and msys, especially the autotools.

Now, the autotools come in two different flavors:
  1) intended for use within an MSys environment for
maintaining/building "native" mingw packages, and
  2) intended for use within an MSysDvlpr environment for
maintaining/building other MSYS packages.

Based on previous discussions on this list, I propose that the autotools
in category #1 follow this naming convention:

autoconf-6-1-mingw32-bin.tar.lzma  (wrapper)
autoconf-6-1-mingw32-src.tar.lzma
autoconf2.1-2.13-4-mingw32-bin.tar.lzma
autoconf2.1-2.13-4-mingw32-src.tar.lzma
autoconf2.5-2.63-1-mingw32-bin.tar.lzma
autoconf2.5-2.63-1-mingw32-src.tar.lzma

These would be configured with prefix=/mingw, and would be packaged from
within /mingw so that they contain:

bin/autoconf-2.63
bin/autoheader-2.63
...
etc.

I'm also open to (a) possibly splitting the documentation out into a
-doc pkg for each, and/or (b) using -dev in preference to -bin for the
package that contains the actual scripts.  However, this becomes tricky
with regards to gettext.  There's
  (a) the package that contains the DLLs (-dll-N, obviously)
      -- perhaps multiple, to track different libraries with different
         evolving API numbers. e.g libintl vs. libasprintf.
  (b) the package that contains the gettext utility programs
  (c) the package that contains the import libs, static libs, and header
files
  (d) the package that contains the documentation for the utilities
  (e) the package that contains the API documentation for the libraries
  (f) the package that contains the GIANT set of examples
I lean towards -bin for (b), -dev for (c), and combining all of (d-f) as
-doc.  BUT, if the gettext *utilities* are in -bin, then why shouldn't
the autoconf *utilities* ALSO be in a -bin package?  That's my reasoning
for using -bin, in the examples above.


The real controversy here is the use of "mingw32" as the subsystem
identifier.  Technically, these packages are *msys* utilities, because
they depend on msys-perl, msys-bash, etc.  However, the question is how
to distinguish THESE packages from the msysdvlpr ones -- I don't really
like "-msys-"  vs.  "-msysdvlpr-".  And besides, these really should
reside in /mingw/bin, so that the typical PATH settings which have
/mingw/bin precede /usr/bin when !msysdvlpr will enable the typical
mingw user to have default access to the "mingw32"-specific autotool
utilities, and not "accidentally" get the msys-specific ones.

I'm also planning to create these packages using tar's
--hard-dereference option, so that hardlinks get turned into copies when
the tarball is created.  This will enable non-msys-aware unpackers like
7zip or mingw-native-tar to unpack without issue.

I'd create new "Packages" (in the SourceForge sense) as follows:

MinGW Utilities: autoconf [*]
MinGW Utilities: automake
MinGW Utilities: libtool
MinGW Utilities: gettext [**]

[*] This "package" would contain multiple "Releases" (in sourceforge lingo):
   autoconf-wrapper
   autoconf2.1
   autoconf2.5
where these these "Releases" would contain the obvious files (the '2.5'
is not a typo.  This represents the 2.5x API of autoconf, which was a
significant change from 2.1x, but which has not changed significantly
even though we are now at 2.63).  Eventually, I could see the
autoconf2.5 "release" containing also tarballs/dists derived from
upstream autoconf-2.64, -2.65, etc.  Ditto the autoconf-wrapper
"release" containing tarballs/dists derived from (upstream) -7, -8, etc.

[**] I'm not sure whether this is a "utility" or a should be "MinGW
Libs: gettext (libintl?)" like "MinGW Libs: libiconv".  On the one hand,
for development purposes it provides a lot of utility programs like
gettext.exe, xgettext.exe, msgcat.exe.  On the other hand, it contains
the libintl library (among others).  At least in this case, tho, I am
*sure* it deserves the -mingw32- subsystem moniker -- all the
executables and libraries would be native win32 ones, even though (e.g.)
the autopoint script is a shell script requiring (msys)bash.



The autotools in category #2 would be configured with prefix=/usr, and
would be packaged from within /usr so that they, too, look like:

bin/autoconf-2.63
bin/autoheader-2.63

Naturally, it is up to the end user (or our installation program) to
unpack the "mingw32" version and the "msys" version in the correct,
non-conflicting, locations.  Those autotools that have compiled
components would naturally be compiled using the msysDVLPR gcc-2.95.3
compiler.

Proposed package naming convention for these msys/msysdvlpr packages:

autoconf-6-1-msys-bin.tar.lzma  (wrapper)
autoconf-6-1-msys-src.tar.lzma
autoconf2.1-2.13-1-msys-bin.tar.lzma
autoconf2.1-2.13-1-msys-src.tar.lzma
autoconf2.5-2.63-1-msys-bin.tar.lzma
autoconf2.5-2.63-1-msys-src.tar.lzma

(Or, perhaps the subsystem should be versioned, as in -msys-1.0.12- ?)

In a manner similar to the discussion above, I'd create "Packages" (in
the SourceForge sense) as follows (note that, at present, the autotools
in category #2 are currently distributed as part of the "MSYS System
Builder" "Package").

MSysDvlpr Utilities: autoconf
MSysDvlpr Utilities: automake
MSysDvlpr Utilities: libtool
MSysDvlpr Utilities: libiconv [***]
MSysDvlpr Utilities: gettext  [***]

[***] again, "MSysDvlpr Utilities", or "MSys Libs"? Not sure.
Naturally, the DLLs themselves would be named 'msys-foo-N.dll'

(Aside: I think, eventually, the "MSys Supplementary Tools" package
should be retired, and its contents dispersed to multiple separate "MSys
 Utilities: Foo" or "MSys Libs: Foo" Packages.)



Concerning .lzma: IIRC, all of the known mingw setup/installer programs
support .lzma (tho some may not yet support .xz).  Plus, .lzma does a
MUCH better job when a tarball contains multiple copies of the same
(large) file than does .gz or .bzip2 -- and this eventuality will be
quite common if packages use the --hard-dereference option, as I think
they should, for portability.  We presently have an lzma utility in
msys, and an --lzma-capable tar in msys (1.0.12).  We do not YET have a
native utility for that, but that is on my list for this round of
package updates.

(Another aside: I plan to eventually create binary mingw packages for:
   zlib
   bzip2
   xz
   libarchive
specifically so that we can distribute/have available a
statically-linked native win32 bsdtar.exe that supports lzma, gz, and
bzip2 without delegating to external decompression, which IIRC GNU tar
doesn't do well on native win32.  I'm NOT making a win32 native openssl,
so this bsdtar won't support the mtree format and its required
cryptographic hashes <g>).



Now, the autotools are (mostly) just scripts, so "which compiler to use"
is not a concern.  However, when I get to libtool and gettext (and maybe
libiconv, if Keith's current 1.13 is insufficient for some unforeseen
reason) "which compiler" WILL be an issue.

I'd LIKE to use Aaron's 4.4.0 release -- but (a) I can't find it
anywhere, (b) I'm not sure it actually exists anywhere but on Aaron's
computer, and (c) rumor has it that "4.4.0 is broken OOTB".  I *don't*
want to use the 1-year-old "release candidate" 4.3.0.  I *don't* want to
use the 4-year-old 3.4.5.  So, unless there are strong objections, for
now I'm planning to use TDM's 4.4.0-dw2 compiler, with plans to rebuild
any packages that need it, using Aaron's 4.4.0, once that compiler is
actually available in -beta or -rc form. (we're not talking about a lot
of non-script packages, here.  Just libiconv(?), gettext, and libtool.
Plus maybe the four culminating in libarchive/bsdtar, listed above).

Comments, Questions?

--
Chuck


------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[John E. / TDM]

Charles Wilson wrote:
> So, unless there are strong objections, for
> now I'm planning to use TDM's 4.4.0-dw2 compiler, with plans to rebuild
> any packages that need it, using Aaron's 4.4.0, once that compiler is
> actually available in -beta or -rc form. (we're not talking about a lot
> of non-script packages, here.  Just libiconv(?), gettext, and libtool.
> Plus maybe the four culminating in libarchive/bsdtar, listed above).
>
> Comments, Questions?
>  

I certainly don't object, but would like to mention that there is one
bug reported on TDM-GCC 4.4.0 with a chance of affecting these tools'
usability. Bug 2803234 [1] reports that a std::ofstream (ergo, this
probably only affects C++ programs) cannot seek past 2GB. I haven't had
the opportunity to track down the source of this bug yet.

If none of the tools you compile are written using C++ iostreams, then
this probably wouldn't affect them.

Looking forward to using the new packages!

-John E.

[1]
<http://sourceforge.net/tracker/?func=detail&aid=2803234&group_id=200665&atid=974439>


------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

John E. / TDM wrote:
> I certainly don't object, but would like to mention that there is one
> bug reported on TDM-GCC 4.4.0 with a chance of affecting these tools'
> usability. Bug 2803234 [1] reports that a std::ofstream (ergo, this
> probably only affects C++ programs) cannot seek past 2GB. I haven't had
> the opportunity to track down the source of this bug yet.
>
> If none of the tools you compile are written using C++ iostreams, then
> this probably wouldn't affect them.

The only C++ library in the set is libasprintf, which is part of gettext
[*].  However, that library is intended for formatting error messages
using std::ostreams, but in a manner that supports easy i18n.  That is:

cerr << autosprintf ("syntax error in %s:%d: %s", filename, line, errstring)

is a lot easier to internationalize than

cerr << "syntax error in " << filename << ":" << line << ": " << errstring;

because the former lets you rearrange words to follow language-specific
grammar rules (especially as libasprintf's autosprintf class supports
"positional specifiers" if your C [s]printf routines do).

BUT...error messages of this sort really should not be 2GB.  I dunno
about you, but I won't read them if they're that long.

[*] To support Bruno's wild and wacky way of handling DLLs on "woe32",
he compiles and links the gettext utility applications using C++ even
though the code itself is C.  So, it still uses stdout/stderr, not
std::cout or std::cerr. So this buglet shouldn't matter here, either.

But thanks for the heads up.

--
Chuck

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Sunday 21 June 2009 23:38:19 Charles Wilson wrote:

> I propose that the autotools
> in category #1 follow this naming convention:
>
> autoconf-6-1-mingw32-bin.tar.lzma  (wrapper)
> autoconf-6-1-mingw32-src.tar.lzma
> autoconf2.1-2.13-4-mingw32-bin.tar.lzma
> autoconf2.1-2.13-4-mingw32-src.tar.lzma
> autoconf2.5-2.63-1-mingw32-bin.tar.lzma
> autoconf2.5-2.63-1-mingw32-src.tar.lzma
>
> These would be configured with prefix=/mingw, and would be
> packaged from within /mingw so that they contain:
>
> bin/autoconf-2.63
> bin/autoheader-2.63
> ...
> etc.

Looks good to me.

> I'm also open to (a) possibly splitting the documentation out into
> a -doc pkg for each,

Makes sense, if it's easily separated out.

> and/or (b) using -dev in preference to -bin
> for the package that contains the actual scripts.

I'd be inclined to stick with -bin; -dev really implies header files,
libraries, (and maybe associated docs, if not separated).  Autoconf
doesn't provide such components, so a -dev package here would seem
to be an anomaly.

> The real controversy here is the use of "mingw32" as the subsystem
> identifier.  Technically, these packages are *msys* utilities,
> because they depend on msys-perl, msys-bash, etc.

Yes, and to classify them as such really does seem more natural, than
to suggest that they may be MinGW utilities, which most would expect
to be able to run independently of MSYS.

> However, the
> question is how to distinguish THESE packages from the msysdvlpr
> ones -- I don't really like "-msys-"  vs.  "-msysdvlpr-".

I take your point, but I am concerned that autoconf-*-mingw32 may
lead to end user confusion, and an expectation that these should run
without MSYS, where in fact this isn't the case.  If -MSYS- alone is
to serve for tools used in MSYS with the MINGW32 host personality --
as is the case for the majority of other packages -- then we really
do need a distinct identifier for MSYSDVLPR.  Whether that ends up
as -MSYSDVLPR-, -MSYS-DVLPR-, -MSYS-SDK- or some other moniker --
I'm open to suggestions -- it really *shouldn't* be just -MSYS-.

> And
> besides, these really should reside in /mingw/bin, so that the
> typical PATH settings which have /mingw/bin precede /usr/bin when
> !msysdvlpr will enable the typical mingw user to have default
> access to the "mingw32"-specific autotool utilities, and not
> "accidentally" get the msys-specific ones.

Agreed.  However, I've never really understood why the one set of
autotools can't suffice for both purposes, (with the exception of
libtool perhaps, and gettext which I don't view as a natural
component of the autotools in any case).

> (Another aside: I plan to eventually create binary mingw packages
> for:
>    zlib
>    bzip2
>    xz

I was planning to do these myself; (already have them built, and just
the split, packaging and distribution to complete).  Do you want to
take them over, or shall I continue with them?

>    libarchive

However, I ran into a brick wall with this -- and please *don't* tell
me I need to kludge it, by using CMake to generate a build system.  
If I can't build it with a simple

  ../path/to/configure --build=i686-pc-linux --host=mingw32 ...

I consider it to be broken.  (FTR, libarchive-2.7.0 appears to
configure fine, but the source then fails to compile correctly; it
breaks at the outset, in libarchive/archive-entry.c, which is the
very first file in the compilation sequence)[*].

> specifically so that we can distribute/have available a
> statically-linked native win32 bsdtar.exe that supports lzma, gz,
> and bzip2 without delegating to external decompression,

Yep.  That was my motivation for playing with zlib, libbz2, liblzma
and libarchive, but I wasn't aiming for a standalone bsdtar -- I'd
like to integrate the unpacking function directly into mingw-get.
I started out with the groundwork John E. has already put in place,
(but eschewing his decomposition of the prerequisite libraries in
favour of linking against the full library code from upstream).  I
had no difficulty in getting the decompression filters working --
gzip from libz, bzip2 from libbz2, lzma and xz from liblzma.  Rather
than hack around the issues with libarchive, I took Tim Kientzle's
untar.c, and adapted it.

> which IIRC GNU tar doesn't do well on native win32.

Maybe.  I don't know.  I've never attempted to build GNU tar for
native w32.  My understanding is that bsdtar is better in any case,
and I was disappointed that libarchive failed to build.

> I'm NOT making a win32
> native openssl, so this bsdtar won't support the mtree format and
> its required cryptographic hashes <g>).

No problem with that; I don't think we need anything beyond ustar
format archives.

[*] Yes, I am aware that there are known issues with 2.7.0 and MinGW;
the issues I saw -- very quickly -- didn't seem to be related to the
issues I saw reported on the libarchive wiki.

--

Regards,
Keith.

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Aaron W. LaFramboise-2]

Charles Wilson wrote:

> I'd LIKE to use Aaron's 4.4.0 release -- but (a) I can't find it
> anywhere, (b) I'm not sure it actually exists anywhere but on Aaron's
> computer, and (c) rumor has it that "4.4.0 is broken OOTB".

I will be uploading 4.4.0 today, all languages, final release, by around
06:00 UTC.  There's a lot of stuff that's broken, but as usual, C
language stuff is solid as usual, so regarding what you intend to do, I
think this compiler will work for you.

There's about a billion minor bugs, which are each individually probably
major to someone.  This is nothing new to MinGW series compilers.  The
first thing I'm going to do after posting the announcement is post a
call-for-help highlighting the areas in GCC that I think are most in
need for attention.  There's a lot of talented developers in the MinGW
community; maybe just having a TODO list would be enough to get people
interested. :)


------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Chris Sutcliffe-2]

Hey Aaron,

> I will be uploading 4.4.0 today, all languages, final release, by around
> 06:00 UTC.  There's a lot of stuff that's broken, but as usual, C
> language stuff is solid as usual, so regarding what you intend to do, I
> think this compiler will work for you.

That's great news!  Just to clarify, in your opinion, is this 4.4.0
build stable enough (given the issues) to become the default compiler,
or do we still stick with 3.4.5 (given it's issues) to generate the
MinGW packages?

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Keith Marshall wrote:
> On Sunday 21 June 2009 23:38:19 Charles Wilson wrote:
>> I propose that the autotools
>> in category #1 follow this naming convention:
>>
>> autoconf-6-1-mingw32-bin.tar.lzma  (wrapper)
> Looks good to me.

Except that this contradicts your comments below, concerning -mingw- vs.
-msys- vs. -msysDVLPR-

>> I'm also open to (a) possibly splitting the documentation out into
>> a -doc pkg for each,
>
> Makes sense, if it's easily separated out.

Easy peasy.

>> and/or (b) using -dev in preference to -bin
>> for the package that contains the actual scripts.
>
> I'd be inclined to stick with -bin; -dev really implies header files,
> libraries, (and maybe associated docs, if not separated).  Autoconf
> doesn't provide such components, so a -dev package here would seem
> to be an anomaly.

That was my thought as well.

>> The real controversy here is the use of "mingw32" as the subsystem
>> identifier.  Technically, these packages are *msys* utilities,
>> because they depend on msys-perl, msys-bash, etc.
>
> Yes, and to classify them as such really does seem more natural, than
> to suggest that they may be MinGW utilities, which most would expect
> to be able to run independently of MSYS.
>
>> However, the
>> question is how to distinguish THESE packages from the msysdvlpr
>> ones -- I don't really like "-msys-"  vs.  "-msysdvlpr-".
>
> I take your point, but I am concerned that autoconf-*-mingw32 may
> lead to end user confusion, and an expectation that these should run
> without MSYS, where in fact this isn't the case.  If -MSYS- alone is
> to serve for tools used in MSYS with the MINGW32 host personality --
> as is the case for the majority of other packages -- then we really
> do need a distinct identifier for MSYSDVLPR.  Whether that ends up
> as -MSYSDVLPR-, -MSYS-DVLPR-, -MSYS-SDK- or some other moniker --
> I'm open to suggestions -- it really *shouldn't* be just -MSYS-.

So here's the real kicker: libtool.  From your reasoning, then, we
should have:

libtool-2.2.7a-1-mingw32-dll-7.tar.lzma (contains a mingw DLL)
libtool-2.2.7a-1-msys-bin.tar.lzma      (contains an (msys)bash script)
libtool-2.2.7a-1-???-doc.tar.lzma       (ok, now I'm confused)
libtool-2.2.7a-1-???-src.tar.lzma       (and this makes my head hurt)

I'd guess there would be a lot of packages like that. Take your/my
native build of bzip2. The .exe's, dll's, and libs are all -mingw-. BUT,
bzip2 also provides
   bzcmp
   bzdiff
   bzegrep
   bzfgrep
   bzgrep
   bzless
   bzmore
which are all (msys)sh scripts.  So, my -bin package which contains
these scripts, plus the perfectly usable native bzip2.exe, is what?

bzip2-1.0.5-1-mingw32-bin.tar.lzma
bzip2-1.0.5-1-msys-bin.tar.lzma

I think we're going to have to accept the following:
  1) sometimes there is no "correct" choice -- all choices are to
     some degree wrong.
  2) we should err on the side of least surprise (or, when all choices
are to some extent surprising, fall back to the hobgoblin of little
minds like my own: consistency)

So, for my bzip2 example, I'd definitely call it -mingw32-, and perhaps
add a blurb to the ReleaseNotes that "executables and libraries provided
by this package are native win32, but some of the scripts provided
require msys to operate correctly" and let it go.

For libtool...what's more important: libltdl-7.dll is mingw32, or
libtool requires (a lot) of msys support?  I could go either way...punt
to "whatever we decide for the rest of the autotools".  Principle of
least surprise: all the autotool packages for MSYS-as-MinGW-personal
should at least use the SAME subsys id.

Concerning gettext, I do consider to be an autotool because of
autopoint.  libintl-2.dll is mingw.  All the .exe utilities are mingw.
But autopoint is an (msys)sh script, and requires (msys)cvs.  MOST of
gettext is mingw32.

Similarly, (the native build of) gettext's apps and dll's depend on (the
native build of) libiconv -- which as currently distributed contains
nothing which relies on msys.  So certainly libiconv should be -mingw32-
(-msys- would be just silly, AND misleading).

But, back to "use the SAME subsys id" -- by my argument, libiconv and
gettext should be -mingw32-.  BUT gettext::autopoint requires msys
support programs.

Now, that just knocks the legs out of the argument that the libtool
"script" forces all of the libtool packages to use the -msys- subsys id.
A tie (libtool-bin vs. libtool-dll) goes to the runner (gettext &
libiconv use -mingw32-, and gettext-bin contains autopoint, just like
libtool-bin contains libtool proper).

Which finally brings us back to automake/autoconf.  Well, if
libtool/gettext/libiconv all claim -mingw32-, these boys should too.

>> And
>> besides, these really should reside in /mingw/bin, so that the
>> typical PATH settings which have /mingw/bin precede /usr/bin when
>> !msysdvlpr will enable the typical mingw user to have default
>> access to the "mingw32"-specific autotool utilities, and not
>> "accidentally" get the msys-specific ones.
>
> Agreed.  However, I've never really understood why the one set of
> autotools can't suffice for both purposes, (with the exception of
> libtool perhaps, and gettext which I don't view as a natural
> component of the autotools in any case).

While autoconf and automake are platform-agnostic [*], libtool is not,
as you point out.  But it's worse: the autotools expect to work
together, in that aclocal creates aclocal.m4 using m4 fragments from
  1) local m4/ dir
  2) $prefix/share/aclocal
  3) $prefix/ahare/aclocal-X.Y
  4) wherever $prefix/share/aclocal/.dirlist says
AND the aclocal.m4 it creates is supposed to work with the
autoconf/automake you use.  Ditto libtoolize is going to copy ITS
$ltprefix/share/aclocal/libtool.m4 & friends into the local m4/ dir for
aclocal to use -- and that better match the ltmain.sh you have, as well.


[*] contrary to early reports from long ago, autoconf and automake
should NOT be configured with the typical mingw '--prefix=`cd /mingw &&
pwd -W`'.  This is because they are entirely comprised of perl and shell
scripts, and in our environment rely on (msys)perl and (msys)bash. Thus,
throwing C:\Dos\Style\Path\With Spaces\ at them just doesn't work.  They
actually want --prefix=/mingw (or $unix_prefix_of_your_choice).




Then, consider all the libraries that stick their .m4 files (esp.
gettext! Wow, it supplies almost as many .m4 files as automake itself)

Now, suppose I have only ONE common installation of autoconf and
automake, to be used by both msysdvlpr and msys-as-mingw environments.
Suppose this is the "msys" build of those tools, and thus was configured
with --prefix=/usr NOT --prefix=/mingw.  There is only one search path
for .m4 files -- /usr/share/aclocal/ and friends.

Well, I've got a native build of libxml configured and installed, like a
good little mingw user, in /mingw.  I'm developing a package that uses
that library, and I want to reference libxml.m4 from my package's
configure.ac.  /usr/bin/aclocal will look in /usr/share/aclocal/ and
friends, and will NOT find libxml.m4 unless
  a) I explicitly use 'aclocal -I /mingw/share/aclocal'
  b) I add ACLOCAL_FLAGS = -I /mingw/share/aclocal to my project's
     Makefile.am.  That's not very cross-platform...
  c) I add /mingw/share/aclocal to /usr/share/aclocal/.dirlist
     However, this has other problems, in that it breaks the msysdvlpr
usage...there's now an .m4 file in aclocal's search path associated with
a library for which I don't have an msys build (so what? you say. Well,
you're right: this isn't REALLY a problem. It's not presence/vs/absence
that is the real trouble. It's version mismatch. See below)

None of these choices seem good to me.  It oughta Just Work without
extra effort on the developer's part -- or platform specific
ACLOCAL_FLAGS settings in a supposedly cross-platform Makefile.am.

So here's the REAL problem with c): different VERSIONS of an .m4 file.
We *will* have multiple versions -- native and msys -- of libiconv and
libintl/gettext.  Each provides lots of .m4 files.  These .m4 files are
not always intercompatible across versions.

So, to allow a single autoconf installation, I/We have to ensure that
libiconv-win32 and libiconv-msys are always kept in sync, so that the
.m4 files stay compatible. Ditto libintl-win32 and libintl-msys.  AND we
have to ensure that all USERS always upgrade both simultaneously if they
have them installed at all.

IMO it's easier to simply have a separate entire autotoolchain for msys,
and a separate entire autotoolchain for native.  What 'subsys id' we
give em', I dunno.  See above.

Plus, this actually simplifies things a bit. I can distribute just One
True Autoconf Version and One True Automake Version for msysdvlpr (plus,
recall that the msys versions are patched to support the -msys- $host
triple, which Earnie explicitly does NOT want leaking outside of the
msysdvlpr environment).

The mingw autotoolchains can be all tricked out with multiple versions
and wrapper scripts and whatnot -- and I don't have to worry if all that
junk actually WORKS in the msysdvlpr environment.  I just have to ensure
that the One True Version works in msysdvlpr.

>> (Another aside: I plan to eventually create binary mingw packages
>> for:
>>    zlib
>>    bzip2
>>    xz
>
> I was planning to do these myself; (already have them built, and just
> the split, packaging and distribution to complete).  Do you want to
> take them over, or shall I continue with them?

It's probably better if I take over xz just for synergy. I'm already
bouncing patches back and forth with Lasse Collin concerning the build
issues.

I also maintain the cygwin builds of zlib, mingw-zlib [*], bzip2, and
mingw-bzip2 [*], so I could do those two as well, but in the interests
of preserving my sanity, how about you go ahead with zlib and bzip2?

[*] these are actually mingw-native builds, but are built using cygwin
gcc -mno-cygwin, are intended SOLELY to support developers of setup.exe,
and whose DLL names are munged to avoid conflict with anything the MinGW
project might ever distribute. There will soon also be a cygwin mingw-xz
package...

>>    libarchive
>
> However, I ran into a brick wall with this -- and please *don't* tell
> me I need to kludge it, by using CMake to generate a build system.  
> If I can't build it with a simple
>
>   ../path/to/configure --build=i686-pc-linux --host=mingw32 ...
>
> I consider it to be broken.  

I agree. I'm actually one of the project members for libarchive. I've
helped to get it building on cygwin (configure/make) but haven't had a
chance to do the same for mingw.  That's already on my list...

> (FTR, libarchive-2.7.0 appears to
> configure fine, but the source then fails to compile correctly; it
> breaks at the outset, in libarchive/archive-entry.c, which is the
> very first file in the compilation sequence)[*].

Cute.  That always gives me warm fuzzies.

>> specifically so that we can distribute/have available a
>> statically-linked native win32 bsdtar.exe that supports lzma, gz,
>> and bzip2 without delegating to external decompression,
>
> Yep.  That was my motivation for playing with zlib, libbz2, liblzma
> and libarchive, but I wasn't aiming for a standalone bsdtar -- I'd
> like to integrate the unpacking function directly into mingw-get.

Well, once the libraries are available, all sorts of things become possible.

> I started out with the groundwork John E. has already put in place,
> (but eschewing his decomposition of the prerequisite libraries in
> favour of linking against the full library code from upstream).

That's my preferred approach, too.

> I
> had no difficulty in getting the decompression filters working --
> gzip from libz, bzip2 from libbz2, lzma and xz from liblzma.  Rather
> than hack around the issues with libarchive, I took Tim Kientzle's
> untar.c, and adapted it.

That'll work.

>> which IIRC GNU tar doesn't do well on native win32.
>
> Maybe.  I don't know.  I've never attempted to build GNU tar for
> native w32.  My understanding is that bsdtar is better in any case,
> and I was disappointed that libarchive failed to build.

GNU tar tries to fork/exec external decompression programs except for
compress, gz, and bz2.  Without lots of TLC (or gnulib code) this
doesn't work on native win32 the way GNU tar expects it to.

> [*] Yes, I am aware that there are known issues with 2.7.0 and MinGW;
> the issues I saw -- very quickly -- didn't seem to be related to the
> issues I saw reported on the libarchive wiki.

Well, it oughta work. And it WILL work. Just as soon as I can get to it. <g>

--
Chuck

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Aaron W. LaFramboise wrote:
> I will be uploading 4.4.0 today, all languages, final release, by around
> 06:00 UTC.  There's a lot of stuff that's broken, but as usual, C
> language stuff is solid as usual, so regarding what you intend to do, I
> think this compiler will work for you.

Outstanding.  I wasn't really trying to give you a poke; I've been
following the binutils/gcc lists and see that there are/have been issues.

--
Chuck


------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Aaron W. LaFramboise-2]

Chris Sutcliffe wrote:

> Hey Aaron,
>
>> I will be uploading 4.4.0 today, all languages, final release, by around
>> 06:00 UTC.  There's a lot of stuff that's broken, but as usual, C
>> language stuff is solid as usual, so regarding what you intend to do, I
>> think this compiler will work for you.
>
> That's great news!  Just to clarify, in your opinion, is this 4.4.0
> build stable enough (given the issues) to become the default compiler,
> or do we still stick with 3.4.5 (given it's issues) to generate the
> MinGW packages?

Yes, I think it is stable enough for general use.

Most languages other than C have a lot of issues.  However, for most of
them, this is nothing new on MinGW.  There are no regressions that I am
familiar with that are so serious as to not warrant a final release.

As some individuals have pointed out, there's really no way MinGW GCC
can proceed without getting a full, non-testing release.  As people
start using 4.4, we can get a feel for what problems are important, and
do what we can with our limited manpower to fix them.

As Agner Fog mentioned on the GCC list not too long ago, recent GCC is
actually quite good and is very competitive with other i386 compilers.
He said, "I think that when gcc gets a reputation as the best compiler,
more people will be motivated to update cygwin/mingw."  Let's hope he's
right.

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Cesar Strauss-2]

On Sun, Jun 21, 2009 at 7:38 PM, Charles Wilson <cwilso11@...> wrote:

I'm gearing up to refresh some of the packages I've created in the past
for mingw and msys, especially the autotools.

Thanks!
 

Now, the autotools come in two different flavors:
 1) intended for use within an MSys environment for
maintaining/building "native" mingw packages, and
 2) intended for use within an MSysDvlpr environment for
maintaining/building other MSYS packages.

Based on previous discussions on this list, I propose that the autotools
in category #1 follow this naming convention:

autoconf-6-1-mingw32-bin.tar.lzma  (wrapper)
autoconf-6-1-mingw32-src.tar.lzma
autoconf2.1-2.13-4-mingw32-bin.tar.lzma
autoconf2.1-2.13-4-mingw32-src.tar.lzma
autoconf2.5-2.63-1-mingw32-bin.tar.lzma
autoconf2.5-2.63-1-mingw32-src.tar.lzma

These would be configured with prefix=/mingw, and would be packaged from
within /mingw so that they contain:

bin/autoconf-2.63
bin/autoheader-2.63
...
etc.

Seems reasonable.
 

I'm also open to (a) possibly splitting the documentation out into a
-doc pkg for each,

Seems a good idea.
 

and/or (b) using -dev in preference to -bin for the
package that contains the actual scripts.

I would prefer to reserve -dev to packages providing headers files and libraries. I would include scripts only if they are used to get the build flags (e.g. "foo-config").
 

 However, this becomes tricky
with regards to gettext.  There's
 (a) the package that contains the DLLs (-dll-N, obviously)
     -- perhaps multiple, to track different libraries with different
        evolving API numbers. e.g libintl vs. libasprintf.
 (b) the package that contains the gettext utility programs
 (c) the package that contains the import libs, static libs, and header
files
 (d) the package that contains the documentation for the utilities
 (e) the package that contains the API documentation for the libraries
 (f) the package that contains the GIANT set of examples
I lean towards -bin for (b), -dev for (c), and combining all of (d-f) as
-doc.

Seems right.
 

 BUT, if the gettext *utilities* are in -bin, then why shouldn't
the autoconf *utilities* ALSO be in a -bin package?  That's my reasoning
for using -bin, in the examples above.

Agreed.
 

Regards
Cesar

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Cesar Strauss-2]

Charles Wilson wrote:

The real controversy here is the use of "mingw32" as the subsystem
identifier.  Technically, these packages are *msys* utilities, because
they depend on msys-perl, msys-bash, etc.  However, the question is how
to distinguish THESE packages from the msysdvlpr ones -- I don't really
like "-msys-"  vs.  "-msysdvlpr-".  And besides, these really should
reside in /mingw/bin, so that the typical PATH settings which have
/mingw/bin precede /usr/bin when !msysdvlpr will enable the typical
mingw user to have default access to the "mingw32"-specific autotool
utilities, and not "accidentally" get the msys-specific ones.

I would use the subsystem name to indicate under which root the file should be unpacked:

*-mingw32-* should be unpacked in /mingw
*-msys-* should be unpacked in /usr

Regards,
Cesar


------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Cesar Strauss-2]

Terribly sorry for the MIME/HTML encoded email. I will use Gmail in
IMAP/SMTP mode from now on. Resent in text mode.

Charles Wilson wrote:
> I'm gearing up to refresh some of the packages I've created in the past
> for mingw and msys, especially the autotools.

Thanks!

> Now, the autotools come in two different flavors:
>   1) intended for use within an MSys environment for
> maintaining/building "native" mingw packages, and
>   2) intended for use within an MSysDvlpr environment for
> maintaining/building other MSYS packages.
>
> Based on previous discussions on this list, I propose that the autotools
> in category #1 follow this naming convention:
>
> autoconf-6-1-mingw32-bin.tar.lzma  (wrapper)
> autoconf-6-1-mingw32-src.tar.lzma
> autoconf2.1-2.13-4-mingw32-bin.tar.lzma
> autoconf2.1-2.13-4-mingw32-src.tar.lzma
> autoconf2.5-2.63-1-mingw32-bin.tar.lzma
> autoconf2.5-2.63-1-mingw32-src.tar.lzma
>
> These would be configured with prefix=/mingw, and would be packaged from
> within /mingw so that they contain:
>
> bin/autoconf-2.63
> bin/autoheader-2.63
> ...
> etc.
>

Seems reasonable.

> I'm also open to (a) possibly splitting the documentation out into a
> -doc pkg for each,

Seems a good idea.

> and/or (b) using -dev in preference to -bin for the
> package that contains the actual scripts.

I would prefer to reserve -dev to packages providing headers files and
libraries. I would include scripts only if they are used to get the
build flags (e.g. "foo-config").

>  However, this becomes tricky
> with regards to gettext.  There's
>   (a) the package that contains the DLLs (-dll-N, obviously)
>       -- perhaps multiple, to track different libraries with different
>          evolving API numbers. e.g libintl vs. libasprintf.
>   (b) the package that contains the gettext utility programs
>   (c) the package that contains the import libs, static libs, and header
> files
>   (d) the package that contains the documentation for the utilities
>   (e) the package that contains the API documentation for the libraries
>   (f) the package that contains the GIANT set of examples
> I lean towards -bin for (b), -dev for (c), and combining all of (d-f) as
> -doc.

Seems right.

>  BUT, if the gettext *utilities* are in -bin, then why shouldn't
> the autoconf *utilities* ALSO be in a -bin package?  That's my reasoning
> for using -bin, in the examples above.
>

Agreed.

>
> The real controversy here is the use of "mingw32" as the subsystem
> identifier.  Technically, these packages are *msys* utilities, because
> they depend on msys-perl, msys-bash, etc.  However, the question is how
> to distinguish THESE packages from the msysdvlpr ones -- I don't really
> like "-msys-"  vs.  "-msysdvlpr-".  And besides, these really should
> reside in /mingw/bin, so that the typical PATH settings which have
> /mingw/bin precede /usr/bin when !msysdvlpr will enable the typical
> mingw user to have default access to the "mingw32"-specific autotool
> utilities, and not "accidentally" get the msys-specific ones.

I would use the subsystem name to indicate under which root the file
should be unpacked:

*-mingw32-* should be unpacked in /mingw
*-msys-* should be unpacked in /usr

So, one would be able to know where to unpack the files just by looking
at the file name.

Regards,
Cesar


------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Cesar Strauss wrote:

> Charles Wilson wrote:
>> The real controversy here is the use of "mingw32" as the subsystem
>> identifier.  Technically, these packages are *msys* utilities, because
>> they depend on msys-perl, msys-bash, etc.  However, the question is how
>> to distinguish THESE packages from the msysdvlpr ones -- I don't really
>> like "-msys-"  vs.  "-msysdvlpr-".  And besides, these really should
>> reside in /mingw/bin, so that the typical PATH settings which have
>> /mingw/bin precede /usr/bin when !msysdvlpr will enable the typical
>> mingw user to have default access to the "mingw32"-specific autotool
>> utilities, and not "accidentally" get the msys-specific ones.
>
> I would use the subsystem name to indicate under which root the file
> should be unpacked:
>
> *-mingw32-* should be unpacked in /mingw
> *-msys-* should be unpacked in /usr

Hmmm...I like it (especially as it ratifies my original proposal).  But
let's expand:

The subsys indicates the standard installation prefix for which the
package was configured.  Thus, packages named

*-mingw32-*   were configured using --prefix=/mingw (or, in many
              cases, --prefix=`cd /mingw && pwd -W`. This formulation
              should always resolve to C:\MinGW for official MinGW
              packages).  Thus, the subsys indicates the expected
              directory in which the package should be installed:
                 C:\MinGW
              In almost all cases, these package contain native
              win32 executables and libraries, and are usable without
              an msys installation.  In some few cases, the packages
              may also include *scripts* written in shell or perl. In
              those cases, the scripts may not operate correctly unless
              an msys installation also exists.  One notable group
              of packages that contain such scripts are the family of
              autotool packages with the -mingw32- subsys id.

*-msys-*     were configured using --prefix=/usr. It is expected that
             these packages will be unpacked in /usr == / directory.
             That is, these packages should be unpacked into the
             versioned root directory for msys. Typically, this is
                C:\msys\1.0
             These packages will never have been configured using the
             --prefix=`cd foo && pwd -W` formulation.

> So, one would be able to know where to unpack the files just by looking
> at the file name.

Right.

--chuck

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Earnie]

Quoting Charles Wilson <cwilso11@...>:


>
> *-mingw32-*   were configured using --prefix=/mingw (or, in many
>               cases, --prefix=`cd /mingw && pwd -W`. This formulation
>               should always resolve to C:\MinGW for official MinGW
>               packages).  Thus, the subsys indicates the expected
>               directory in which the package should be installed:
>                  C:\MinGW

I agree.

> *-msys-*     were configured using --prefix=/usr. It is expected that
>              these packages will be unpacked in /usr == / directory.
>              That is, these packages should be unpacked into the
>              versioned root directory for msys. Typically, this is
>                 C:\msys\1.0
>              These packages will never have been configured using the
>              --prefix=`cd foo && pwd -W` formulation.
>

I agree.

>> So, one would be able to know where to unpack the files just by looking
>> at the file name.
>
> Right.
>

Except that it shouldn't matter if they are unpacked in /usr or /mingw  
for 1.0.11 other than for msysDVLPR which I put in /msys.  I put all  
other packages in /usr regardless of if it requires the MSYS dll or  
not.  I understand the support model being represented with what is  
proposed so I'm just throwing a wrench in the wheel.

--
Earnie


------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

On Fri, 26 Jun 2009 17:42 +0000, "Earnie Boyd" wrote:

> Quoting Charles Wilson:
> >> So, one would be able to know where to unpack the files just by looking
> >> at the file name.
> >
> > Right.
> >
>
> Except that it shouldn't matter if they are unpacked in /usr or /mingw  
> for 1.0.11 other than for msysDVLPR which I put in /msys.  I put all  
> other packages in /usr regardless of if it requires the MSYS dll or  
> not.  I understand the support model being represented with what is  
> proposed so I'm just throwing a wrench in the wheel.

I'll take your agreement, and move forward.

But...your wrench is begging for comment:

We're not talking about whether msys DLL is happy about "native"
binaries and "msys" binaries coexisting in the same directory, or
segregated to only-msys and only-mingw directories, or even
scattered/intermingled willy-nilly in a bunch of different directories.
The issue here is for those tools -- be they scripts, binaries, or
utility libraries -- that hardcode their own compilation prefix location
(or some relative path derived from it).  That is, the aclocal script
has a hardcoded reference to ${prefix}/share/aclocal.  autopoint has
hardcoded references. All binaries that use libintl have hardcoded
references to the message catalog location.

Some tools take special care to handle such relocation problems; as it
happens, gettext/libintl and libiconv DO, if they are compiled with
--enable-relocatable (and it hasn't bitrotted on win32 since the last
time I looked at it).  But not every package is so thoughtful.  Now,
IIRC Tor Lillqvist has said "any binary package on win32 that doesn't
handle installation into a different directory is broken".  That's a bit
harsh IMO -- and I'd rather not wait three years for "perfect", when I
can supply "pretty d@mn good" today (or relatively soon), provided we
reach a consensus on these policy issues.

MSYS's 1.0.12 improvements with respect to "mixing native and msys
binaries in /bin" have very little to do with this issue.

Now, if an end-user wants to compile, say, "gettext" for mingw and
install it and all its tools into [/usr]/ -- bully for them.  It'll work
ok (as long as they never try to use the *stock* msysDVLPR tools which
-- according to policy -- will be installed to [/usr]/). If she wants to
recompile ALL "official" mingw binary packages with --prefix=`cd / &&
pwd -W` -- fine and dandy [*].  As you say, the MSYS dll no longer
cares.

But we will be shipping multiple versions of some small set of tools:
libiconv (mingw, msys), gettext (ditto), auto*. They can't ALL go into
"/" -- we'd be silly to deliberate ship packages that, having the same
prefix, can't be installed simultaneously (e.g. msys-libiconv and
mingw-libiconv).  So, for *official* packages...we need *policy*.

[*] probably. Unless the "mingw" package she's compiling clashes with an
already-provided msys one.  Say, cvs for instance.  Then, she's going to
clobber her msys version with the new mingw one...which is fine, as long
as she knows that. She gets to keep all the pieces.

--
Chuck


------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Friday 26 June 2009 18:42:28 Earnie Boyd wrote:
> > *-mingw32-*   were configured using --prefix=/mingw (or, in many
> >               cases, --prefix=`cd /mingw && pwd -W`. This
> > formulation should always resolve to C:\MinGW for official MinGW
> > packages).  Thus, the subsys indicates the expected directory in
> > which the package should be installed: C:\MinGW
>
> I agree.

Sorry; while I see the logic behind this suggestion, I respectfully
*disagree*.  I consider it utterly arcane that a package such as
autoconf, which is 100% dependent on MSYS to do anything even
remotely useful, should be touted as a MinGW package.  There are
many users, who do not use MSYS, (and who may not wish to use it),
and who will expect any package branded as *-mingw32-* to offer at
least a *primary* deliverable which does *not* require MSYS;
autoconf and friends can never meet this criterion.

While we offer packages intended for *three* distinct "user lands", I
don't see how we can expect to achieve the mathematically impossible
feat of describing them with only two unique identifiers; we *need*
an additional unique subsystem identifier, for those packages which
are specifically intended for exclusive use in "MSYS Developer
land"; IMO, *-msys-* cannot suffice for that.

On Friday 26 June 2009 21:47:50 Charles Wilson wrote:
> So, for *official* packages...we need *policy*.

Yes, we need policy, but it needs to be *rational* policy; I don't
think we are yet at a point of consensus, where we can formulate any
such policy.

--

Regards,
Keith.

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Keith Marshall wrote:

> On Friday 26 June 2009 18:42:28 Earnie Boyd wrote:
>>> *-mingw32-*   were configured using --prefix=/mingw (or, in many
>>>               cases, --prefix=`cd /mingw && pwd -W`. This
>>> formulation should always resolve to C:\MinGW for official MinGW
>>> packages).  Thus, the subsys indicates the expected directory in
>>> which the package should be installed: C:\MinGW
>> I agree.
>
> Sorry; while I see the logic behind this suggestion, I respectfully
> *disagree*.  

I knew that you would. This is where we ended over a year ago, when a
similar discussion died without resolution.

> I consider it utterly arcane that a package such as
> autoconf, which is 100% dependent on MSYS to do anything even
> remotely useful, should be touted as a MinGW package.  There are
> many users, who do not use MSYS, (and who may not wish to use it),
> and who will expect any package branded as *-mingw32-* to offer at
> least a *primary* deliverable which does *not* require MSYS;
> autoconf and friends can never meet this criterion.

Are you arguing that the autotool family, intended to support a single
development flow, should have DIFFERENT subsys id's?

For development of         For development of msys
mingw/native apps/libs     apps and libs
=======================    =============================
autoconf-msys              autoconf-msysdvlpr
automake-msys              automake-msysdvlpr
libiconv-mingw             libiconv-msys
gettext- ? [*]             gettext-msys (unless clashes with whatever
                                         resolution goes at left <<)
libtool- ? [**]            libtool-msys (unless clashes...)

The left column, whatever the subsys id, are all installed into one
prefix (most likely /mingw === C:/MinGW).  The right column are all
installed into a different prefix, most likely / == /usr.

Regardless of how [*] and [**] are resolved, I consider the above
"design"...less than sound.

[*] contains libraries and binary utilities that are perfectly happy
native mingw applications.  However, the autopoint and gettextize tools
themselves (aside from xgettext, THE reason gettext is considered an
autotool at all, given when and how it is supposed to be used) are
(msys)shell scripts that invokes/relies on (msys)cvs.  So, are the
gettext subpackages -msys- for that reason? Or -mingw- because the
libraries/exes are native? Or split into pieces where some are one, and
some are the other, yet all derive from the same -src- which
is...non-subsys-id marked?  Insanity...

[**] Similarly here.  libtool and libtoolize are shell scripts, and a
lot of the functionality is provided by m4 files which rely on a working
(msys) m4.exe.  But the binary library is native, as it must be if
you're going to build native apps using the ltdl functionality. Again,
-msys-, -mingw-, or an insane mixture of both?

As I said initially, there is NO single answer that makes perfect sense
in all cases.

A slightly less insane scheme than the one above is

For development of         For development of msys
mingw/native apps/libs     apps and libs
=======================    =============================
autoconf-msys              autoconf-msysdvlpr
automake-msys              automake-msysdvlpr
libiconv-msys              libiconv-msysdvlpr
gettext-msys               gettext-msysdvlpr
libtool-msys               libtool-msysdvlpr

But that's no more rational than my original scheme (-mingw on the left,
-msys on the right) because libiconv-"msys", gettext-"msys", and
libtool-"msys" all contain pieces that are native win32 binaries, useful
by themselves without any MSYS installation at all.

> While we offer packages intended for *three* distinct "user lands", I
> don't see how we can expect to achieve the mathematically impossible
> feat of describing them with only two unique identifiers; we *need*
> an additional unique subsystem identifier, for those packages which
> are specifically intended for exclusive use in "MSYS Developer
> land"; IMO, *-msys-* cannot suffice for that.
>
> On Friday 26 June 2009 21:47:50 Charles Wilson wrote:
>> So, for *official* packages...we need *policy*.
>
> Yes, we need policy, but it needs to be *rational* policy; I don't
> think we are yet at a point of consensus, where we can formulate any
> such policy.

Right. So propose something SPECIFIC rather than general accusations of
irrationality.  Break it down.  I've listed all of the proposed packages
in each work flow, sans subsystem id. Please go thru all 72 packages and
tell me what subsystem id you think each should have.

If you make different choices for packages which fall under the same
workflow, explain why that will not confuse our users trying to figure
out just what in the H*** they are supposed to download.

If you DO choose the same subsys id for all packages under the same
workflow, it will be ipso facto wrong for some of those packages.
Explain why your choice, with its inherent wrongness for certain
packages, is better than any other (uniform) choice, with ITS inherent
wrongness.

targetting mingw development
============================
autoconf-6-1-*-bin.tar.lzma  (wrapper)
autoconf-6-1-*-src.tar.lzma
autoconf2.1-2.13-4-*-bin.tar.lzma
autoconf2.1-2.13-4-*-doc.tar.lzma
autoconf2.1-2.13-4-*-src.tar.lzma
autoconf2.5-2.63-1-*-bin.tar.lzma
autoconf2.5-2.63-1-*-doc.tar.lzma
autoconf2.5-2.63-1-*-src.tar.lzma

automake-4-1-*-bin.tar.lzma   (wrapper)
automake-4-1-*-src.tar.lzma
automake1.4-1.4p6-1-*-bin.tar.lzma
automake1.4-1.4p6-1-*-doc.tar.lzma
automake1.4-1.4p6-1-*-src.tar.lzma
automake1.5-1.5-1-*-bin.tar.lzma
automake1.5-1.5-1-*-doc.tar.lzma
automake1.5-1.5-1-*-src.tar.lzma
automake1.6-1.6.3-1-*-bin.tar.lzma
automake1.6-1.6.3-1-*-doc.tar.lzma
automake1.6-1.6.3-1-*-src.tar.lzma
automake1.7-1.7.9-1-*-bin.tar.lzma
automake1.7-1.7.9-1-*-doc.tar.lzma
automake1.7-1.7.9-1-*-src.tar.lzma
automake1.8-1.8.5-1-*-bin.tar.lzma
automake1.8-1.8.5-1-*-doc.tar.lzma
automake1.8-1.8.5-1-*-src.tar.lzma
automake1.9-1.9.6-3-*-bin.tar.lzma
automake1.9-1.9.6-3-*-doc.tar.lzma
automake1.9-1.9.6-3-*-src.tar.lzma
automake1.10-1.10.2-3-*-bin.tar.lzma
automake1.10-1.10.2-3-*-doc.tar.lzma
automake1.10-1.10.2-3-*-src.tar.lzma
automake1.11-1.11-1-*-bin.tar.lzma
automake1.11-1.11-1-*-doc.tar.lzma
automake1.11-1.11-1-*-src.tar.lzma

libtool-2.2.7a-1-*-bin.tar.lzma
libtool-2.2.7a-1-*-doc.tar.lzma
libtool-2.2.7a-1-*-dev.tar.lzma
libtool-2.2.7a-1-*-dll7.tar.lzma
libtool-2.2.7a-1-*-src.tar.lzma

gettext-0.17-1-*-bin.tar.lzma  [A]
gettext-0.17-1-*-dev.tar.lzma  [B]
gettext-0.17-1-*-dll8.tar.lzma [C]
gettext-0.17-1-*-doc.tar.lzma  [D]
gettext-0.17-1-*-ext.tar.lzma  [E]
gettext-0.17-1-*-src.tar.lzma

libiconv-1.13-1-*-bin.tar.lzma
libiconv-1.13-1-*-dev.tar.lzma
libiconv-1.13-1-*-dll2.tar.lzma
libiconv-1.13-1-*-doc.tar.lzma
libiconv-1.13-1-*-src.tar.lzma


[A] contains just the "gettext-runtime" native gettext executables,
gettext, ngettext, envsubst, and gettext.sh (rats! another
msys-dependent item).   This follows the upstream suggestion about how
to categorize the various utilities provided by gettext.  This package
also provides the libasprintf DLL.

[B] The "gettext-tools" native development utilities like msg*.exe,
xgettext.exe, and (gettextize + autopoint: more msys-dependent stuff!).
Plus the import and static libraries for libintl. Also the
/usr/share/gettext stuff like .m4 files and whatnot.  Contains the
libgettextpo DLL itself, as well as its import and static libraries and
"private" DLLS, mainly because I can't think of a better package to put
them in, while still following our naming convention.  Finally, contains
the libasprintf headers, import, and static libraries.

[C] Contains only libintl-8.dll because that's what most external binary
packages would actually depend on.  They don't need also libasprintf and
libgettextpo.

[D] just man pages and basic documentation

[E] All the other documentation including the gigantic examples directory.

We can discuss the specific breakdown of the gettext package later in a
different thread.  I have some ideas that may help make this tiny corner
of the problem a little more sane.  Just save this email for now if you
have issues with that -- let's keep this (sub)thread focused on the
dadgummed subsys id thing.


targetting msys development
============================
autoconf-2.63-1-*-bin.tar.lzma
autoconf-2.63-1-*-doc.tar.lzma
autoconf-2.63-1-*-src.tar.lzma

automake-1.11-1-*-bin.tar.lzma
automake-1.11-1-*-doc.tar.lzma
automake-1.11-1-*-src.tar.lzma

libtool-2.2.7a-1-*-bin.tar.lzma
libtool-2.2.7a-1-*-doc.tar.lzma
libtool-2.2.7a-1-*-dev.tar.lzma
libtool-2.2.7a-1-*-dll7.tar.lzma
libtool-2.2.7a-1-*-src.tar.lzma

gettext-0.17-1-*-bin.tar.lzma  [A]
gettext-0.17-1-*-dev.tar.lzma  [B]
gettext-0.17-1-*-dll8.tar.lzma [C]
gettext-0.17-1-*-doc.tar.lzma  [D]
gettext-0.17-1-*-ext.tar.lzma  [E]
gettext-0.17-1-*-src.tar.lzma

libiconv-1.13-1-*-bin.tar.lzma
libiconv-1.13-1-*-dev.tar.lzma
libiconv-1.13-1-*-dll2.tar.lzma
libiconv-1.13-1-*-doc.tar.lzma
libiconv-1.13-1-*-src.tar.lzma

--
Chuck

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Aaron W. LaFramboise-2]

My only input to this is that any resolution needs to be respectful of
the fact that non-MSYS tools can be used with MinGW.  In particular,
Cygwin tools and ad-hoc Unix-like tool collections (such as unxutils and
GnuWin32) should be supported as first-order MinGW configuration.
Anything that assumes that MSYS is the only tool configuration for MinGW
is incorrect, and the package structure needs to be set up to
communicate this effectively.

Unfortunately there are goofy and completely wrong things like the
following that crop up if we don't keep this distinction clear.  This
particular instance I still need to look into and have corrected.

 From a recent libtool:
>       *mingw* )
>         lt_sed_naive_backslashify='s|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g'
>         case $build in
>           *mingw* ) # actually, msys
>             # awkward: cmd appends spaces to result
>             lt_sed_strip_trailing_spaces="s/[ ]*\$//"
>             func_to_host_path_tmp1=`( cmd //c echo "$1" |\

It's wrong to assume the system is MSYS, and it is wrong to call
cmd--mostly, because this doesn't actually work on both old model and
late model systems.

Getting this decision-making process wrong could yield substantial
detriment to the future of GNU tools on Windows.

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Earnie]

Quoting "Aaron W. LaFramboise" <aaron77thyme@...>:

> Unfortunately there are goofy and completely wrong things like the
> following that crop up if we don't keep this distinction clear.  This
> particular instance I still need to look into and have corrected.
>
>  From a recent libtool:
>>       *mingw* )
>>         lt_sed_naive_backslashify='s|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g'
>>         case $build in
>>           *mingw* ) # actually, msys
>>             # awkward: cmd appends spaces to result
>>             lt_sed_strip_trailing_spaces="s/[ ]*\$//"
>>             func_to_host_path_tmp1=`( cmd //c echo "$1" |\
>
> It's wrong to assume the system is MSYS, and it is wrong to call
> cmd--mostly, because this doesn't actually work on both old model and
> late model systems.
>

All I can say is that libtool has usually sucked in regards to MinGW.  
I've had to many time manipulate the generated script after the fact  
to do the right thing.  Basing decision on a bad tool isn't a good  
thing to do for us though.

--
Earnie


------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Aaron W. LaFramboise wrote:

> My only input to this is that any resolution needs to be respectful of
> the fact that non-MSYS tools can be used with MinGW.  In particular,
> Cygwin tools and ad-hoc Unix-like tool collections (such as unxutils and
> GnuWin32) should be supported as first-order MinGW configuration.
> Anything that assumes that MSYS is the only tool configuration for MinGW
> is incorrect, and the package structure needs to be set up to
> communicate this effectively.
>
> Unfortunately there are goofy and completely wrong things like the
> following that crop up if we don't keep this distinction clear.  This
> particular instance I still need to look into and have corrected.
>
>  From a recent libtool:
>>       *mingw* )
>>         lt_sed_naive_backslashify='s|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g'
>>         case $build in
>>           *mingw* ) # actually, msys
>>             # awkward: cmd appends spaces to result
>>             lt_sed_strip_trailing_spaces="s/[ ]*\$//"
>>             func_to_host_path_tmp1=`( cmd //c echo "$1" |\
>
> It's wrong to assume the system is MSYS,

No, it is not wrong.  If you tell configure (and thus, libtool) that
--build=mingw32, what is it supposed to think?  Obviously you're not
running on "naked" windows, because libtool itself is a shell script,
not a .bat file.  So SOME assumptions are in order.  But this: "I should
guess that some unspecified collection of unix utilities may or may not
be available, and they may or may not accept dos-style and/or unix-style
paths with some automatic or manual translation mechanism.  But
regardless of what IS or IS NOT available, I should always figure it
out, and do the right thing, with no surprises ever."

No, thanks.  I'm just not smart enough to write and maintain that code
in a shell script.

> and it is wrong to call
> cmd--mostly, because this doesn't actually work on both old model and
> late model systems.

Sorry. Libtool never did specifically support w9x, and it's not about to
start now, seven years after microsoft EOLed it.

Anyway, these complaints are all libtool things, and not specifically a
mingw things (I should know; I wrote that bit).  And it has nothing to
do with the naming convention mingw will use to package upstream
products, so I've changed the title of this subthread.

If there's a problem in the code for those upstream products like
libtool, the correct place to report bugs is bug-libtool@..., and
patches are always appreciated (if not quickly reviewed. Sigh.) at
libtool-patches@....


The code you are looking at is still a work in progress. It's been
stalled now for almost six months, as I have had patches pending on the
libtool-patches list waiting review.  The current cygwin release has the
latest though.

Here's my thinking, for libtool, going forward:

1) "native" mingw ($host=mingw, $build=mingw) == mingw.org's MinGW
compiler on msys (and in that case, cmd IS available. See above WRT
win9x. I could see a well-tested patch to use $COMSPEC instead of
hardcoding cmd.exe, perhaps.)

2) mingw on cygwin: a true cross compiler.  That is, a cygwin-hosted
mingw compiler, either supplied by the cygwin project or built on cygwin
using mingw.org's xscript.  You'd configure the thing you're trying to
build using --build=cygwin --host=mingw.  Note that this scenario is
***NOT*** mingw.org's native gcc accessed from cygwin.  For that...

3) "Lie To Me". Running on cygwin, but using the mingw.org gcc.  You'd
configure using --build=mingw --host=mingw (that's the "lie", because
--build is really cygwin) --- BUT, specifically related to the code
fragment above, you'd set a libtool cache variable before running
configure so it would DTRT, and not the (cmd ...) thing libtool would
normally do on "native" (that is, mingw/msys) builds.

export lt_cv_to_host_path_cmd=func_cygwin_to_mingw_path_convert

Normally, for "native" [mingw/msys] builds, that variable is
autodetected to be func_msys_to_mingw_path_convert. this is obviously
not right when build is actually cygwin.  AND, normally you'd simply be
told "don't lie to your tools". But, because this particular lie
currently works fairly well for a lot of people, I want to ensure that
it continues to work in the future.


4) wine. a linux-hosted mingw cross compiler. Works like a normal cross
compiler, but detects WINE and DTRT so that uninstalled executables --
including test programs -- can be run from WINE via the linux binfmt
kernel extension.


I have most of this working fairly well now, if not extensively tested yet.


My primary goals with my ongoing libtool mods have been:
1) get libtool on mingw/msys working properly again, without the need
for /etc/config.site
2) get wine-hosted mingw and cygwin target cross compiles working in
lt-2.2 at least as well, and hopefully better than, they did in lt-1.5
3) *DO NOT BREAK* the gcc developer-favored approach for windows-hosted
development: Danny Smith and Aaron both seem to use mingw (native) gcc
from within cygwin.  This MUST continue to work properly -- although it
may require an extra environment setting or two.  I figure those guys
aren't babes in the woods; they can handle it.

Now, as far a using gnuwin32 tools or unxutils to "host" libtool?
Sorry, I don't have NEAR enough cycles to make that work out of the box.
I won't go out of my way to break it, but most Gnuwin32 "installations"
are too haphazard about what is or is not present to make any kind of
functionality assumptions.  If it works for you, great. Otherwise...you
can keep all the pieces.

--
Chuck

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr