From: Keith M. <kei...@us...> - 2009-06-22 19:54:18
|
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. |