From: Keith M. <kei...@us...> - 2009-04-23 19:59:36
|
On Tuesday 21 April 2009 03:42:48 Aaron W. LaFramboise wrote: > > My instincts tell me we should be adding a DLL version number > > suffix, as in > > > > gcc-objc-4.4.0-20090413-mingw32-beta-dll-2.tar.gz > > > > but I'm not sure how best to classify those with multiple DLLs, > > at differing internal versions; > > I'm not sure either, and I think this will depend on the > resolution of exactly what our dependency technology ends up > looking like. I guess it doesn't really matter what DLL version number appears in the tarball name, as long as it changes (increments) monotonously and uniquely, when any one of the constituent DLLs changes its version number, (including reversions). > One data point is that non-testing versions will never change the > ABI within a major revision. For example, for all minor versions > X in 4.4.X-mingw32, libobjc will always be version 2, and should > be completely interchangeable, modulo bug fixes. If that remains strictly the case, then perhaps the change in the package version number would be sufficient as a discriminator; however, adding a DLL version tag now, even if somewhat arbitrary, helps guard against possible loss in consistency later, should the rule ever change. > > The package names look good, with the proviso that the support > > DLL packages belong in separate FRS container "package sets", > > whence they may be shared by other dependent packages; > > This is really your decision, as an administrator. What do you > suggest as far as the breakup and names for these? If it > simplifies things, we can probably merge all of the GCC > components into a single one, instead of having a separate > component for each minor version. For a full package set, an "FRS Package" per library package, with name: "MinGW Libs: libname", as I've now done for libiconv-1.13. For any you just want to post as DLL+source for now, as long as the tarball names are appropriately assigned, (as your proposed names are), you could just as well bundle them within th GCC-4.4 package for the time being; we can move them later, but we cannot change the tarball file name. > > (libiconv being a > > particular case in point; GCC should be supported by the same > > package as is required by the MSYS autotools, and the existing > > POSIX i18n message catalogue (catgets) development tools). > > For right now, I'm not even bothering with this. Once the > testsuite finishes, if there's no more problems (please please), > I'm rolling the release in the most direct fashion. > > However, once the libiconv package has been migrated to /mingw in > a way that makes sense (at the very least, the usr/local stuff > dropped), I'll rebuild GCC using it. It's not a huge priority > though. As noted above, I've now posted a release candidate for libiconv, as "MinGW Libs: libiconv :: Release Candidate: libiconv-1.13-rc-1"; I hope that you should be able to use the "libiconv-1.13-mingw32-dll-2.tar.gz" and "libiconv-1.13-mingw32-dev.tar.gz" from within that; they unpack with current directory as the package root, placing a pair of DLLs in bin/, headers and import libs in include/ and lib/ respectively, and minimal licensing and release notes in share/doc/libiconv. > By the way, whoever is maintaining the libiconv package should > add themselves to <http://www.mingw.org/wiki/Maintainers>, since > this package will be of particular importance, at least in the > mid-term. Since I've posted it, I guess that would be me then. > (Bonus points if he can figure out how to make the wiki tables > look less ugly.) Yes, it is ugly; I find that wikis generally are. On occasion, I've chosen to post as full HTML, to circumvent some of the more heinous wiki formatting issues. -- Regards, Keith. |