Charles Wilson | 29 May 01:52 2010
Picon
Picon

Tentative meta package manifests

I'm pretty hazy on the correct syntax for meta/virtual packages, so I'm
not ready to check these in just yet.  Instead, I'm posting them here
for comments.

There are 4.

msys.xml
========
the top level include-all-the-others manifest. Also defines the
package-group-hierarchy.  Doesn't actually specify any packages of its
own.  Oddity: includes all of the msys-*.xml manifests, but ALSO
references the mingw32-autotool ones; I'm not sure if that's the right
thing to do, but it's necessary because the mingw32-autotools are part
of the msys-developer-toolkit meta package.

msys-base.xml
========
The core installation, approximately equivalent to the old monolithic
MSYS installer. Virtual.

msys-developer-toolkit.xml (alias msys-dtk)
========
Approximately equivalent to the old msys-dtk-1.0.1 monolithic installer.
Odd in that it includes some packages that are msys and install into /,
and the mingw32-autotools that install into /mingw. Also, it needs to
specify a dependency on the msys-base meta package, but I'm not sure how
to do that:
   <requires ge="msys-base-*-msys-*-bin.virtual" />
doesn't seem right, because, well, there is no tarball with that signature.

(Continue reading)

Charles Wilson | 4 Jun 18:43 2010
Picon
Picon

Re: Tentative meta package manifests

On 5/28/2010 7:52 PM, Charles Wilson wrote:
> I'm pretty hazy on the correct syntax for meta/virtual packages, so I'm
> not ready to check these in just yet.  Instead, I'm posting them here
> for comments.

> msys.xml
> msys-base.xml
> msys-developer-toolkit.xml (alias msys-dtk)
> msys-system-builder.xml (alias msys-dvlpr)

Anyone?

--
Chuck

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
Earnie | 4 Jun 22:02 2010
Picon
Picon

Re: Tentative meta package manifests

Charles Wilson wrote:
> On 5/28/2010 7:52 PM, Charles Wilson wrote:
>> I'm pretty hazy on the correct syntax for meta/virtual packages, so I'm
>> not ready to check these in just yet.  Instead, I'm posting them here
>> for comments.
>
>> msys.xml
>> msys-base.xml
>> msys-developer-toolkit.xml (alias msys-dtk)
>> msys-system-builder.xml (alias msys-dvlpr)
>
> Anyone?
>

I don't see anything out of line.  I do question having autoconf-mingw 
and friends instead of autoconf-msys in the msys-dtk package.  It just 
doesn't sound feel right.  I'm sure it has been stated before but what 
is the advantage to autotools-mingw vs autotools-msys?

Earnie

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
Charles Wilson | 4 Jun 23:33 2010
Picon
Picon

Re: Tentative meta package manifests

On 6/4/2010 4:02 PM, Earnie wrote:
> I don't see anything out of line.  I do question having autoconf-mingw 
> and friends instead of autoconf-msys in the msys-dtk package.

autoconf-mingw and friends are the ones you're supposed to use when
developing MinGW apps.  That's what the msys-dtk is FOR, right?

OTOH, autoconf-msys and friends are the ones you /must/ use when
developing MSYS apps (for many reasons, outlined below); that's why
autoconf-msys and friends are in the msys-system-builder (approximately
equivalent to msys-dvlpr) along with msys-gcc and msys-binutils.

This is also why there's only ONE version of msys-autoconf and
msys-automake; while on the mingw side we have a wrapper system and both
autoconf-2.13 and autoconf-2.6x, and all of automake-1.5,1.6...1.11.
For our users, who develop MinGW apps using mingw-gcc, provide
everything.  For msys developers, the requirements are much more modest.

> It just 
> doesn't sound feel right.  I'm sure it has been stated before but what 
> is the advantage to autotools-mingw vs autotools-msys?

It's not an "advantage" -- it's a necessity to have distinct autotool
toolchains for msys and mingw.  For several reasons:

[Sigh. I need to make a keyboard macro for this. I feel like I've
explained it twelve times over the past four years...]

(1)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
(Continue reading)

Earnie | 6 Jun 10:17 2010
Picon
Picon

Re: Tentative meta package manifests

Charles Wilson wrote:
> (3)
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> gettext, libtool (and libiconv) provide binary components, not just
> scripts. Specifically and most importantly, the libltdl and libintl
> DLLs.  Obviously, MinGW applications will rely on mingw versions of
> these DLLs, and MSYS applications will rely on the msys versions.

Ah, ha.  This is the reason.

The original version of msysDTK was built in the MSYS environment and 
the DLL didn't exist.

Earnie

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
Charles Wilson | 6 Jun 19:42 2010
Picon
Picon

Re: Tentative meta package manifests

On 6/6/2010 4:17 AM, Earnie wrote:
> Charles Wilson wrote:
>> (3)
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> gettext, libtool (and libiconv) provide binary components, not just
>> scripts. Specifically and most importantly, the libltdl and libintl
>> DLLs.  Obviously, MinGW applications will rely on mingw versions of
>> these DLLs, and MSYS applications will rely on the msys versions.
> 
> Ah, ha.  This is the reason.
> 
> The original version of msysDTK was built in the MSYS environment and 
> the DLL didn't exist.

Weeeellll, yeah, mostly.  In the (distant) past, gettext wasn't
considered one of the autotools -- and we didn't even attempt to
accomodate i18n -- so it wasn't included at all (and thus, neither was
libiconv):

autoconf-2.56/   cvs-1.11.0/   inetutils-1.3.2/  openssl-0.9.6b/
autogen-5.4.7/   gdbm-1.8.0/   libtool-1.5pre/   perl-5.6.1/
automake-1.7.1/  guile-1.6.0/  openssh-2.9p2-3/  zlib-1.1.3/

Now, we DID ship libtool -- BUT nobody actually used the *installed*
elements /usr/bin/libtool and /usr/lib/libltdl.a. (*)  Rather, they only
ever used /usr/bin/libtoolize and the /usr/share/* elements of libtool.

If our users ever DID try to use /usr/bin/libtool or /usr/lib/libltdl.a
from the original DTK, then there would have been trouble: the installed
libtool script embeds paths to compiler's runtime libraries
(Continue reading)


Gmane