|
From: Julien L. <ju...@fa...> - 2006-03-27 15:38:57
|
On 27/03/2006 13:57, Keith MARSHALL wrote: > Julien Lecomte wrote, quoting me: >> I don't think their [sic] is a *need* to remove the existing libraries >> but it would be *highly* *recommeded*. >> >>> Quoting Earnie Boyd: >>>> That isn't really accomplished easily >>>> with a tarball so we have decided to leave the name the with just a .a > >>>> extension. >>> Something of a cop-out, perhaps, for surely it should be possible to >>> automate the entire process with a script -- would you care to provide >>> and maintain one, Julien? >> Why a script ? Shouldn't it all be done in the makefiles ? > > I was thinking of the scenario wher [sic] a user downloads the prebuilt > binary tarballs, and unpacks those in place of an existing installation. > Such a user won't be using Makefiles, to perform an upgrade. In that case, we can't rely on the user having a mSys installation. Such a script should either be a batch script (ugh !) or run from the installer. > >> Just by modifying the configure script, we can add an option such as >> --with-new-naming (or --with-libtool-naming) that would take care of >> building and installing of whichever the user wants. > > Again, this won't help for a upgrade based on binary tarballs. > > What would be required is:-- > > - Tarballs are built, exclusively with legacy library file names. > - User downloads and unpacks these, overwriting similarly named > files in his/her existing installation. > - User runs script, removing any import libraries with new names, > for which a legacy named replacement is present, and renames the > legacy named replacement with the new name. > Didn't we settle on the fact that using a new naming convention should be reserved to 'power users' and be more or less officially unsupported ? I think we should only let the people who build from sources have the option to use the new naming scheme for now. If the new naming proves to be stable and better, then in a second stage provide the script for all users and make the transition. I'll nevertheless see to create a script, in sh and bat format, and also see to offer a patch of configure/makefile; it'll take my mind off pipes, pty's and terminals for a while. I'll also pre-test it on cygwin, and in a cross-compiler environment. > Note that it isn't acceptable to erase the original installation, > before progressing an upgrade; that could remove more than the > upgrade will replace, particularly if the user is in the habit of > installing mingwPORTs, or other additional packages, into the > MinGW tree, (which *is* the default for mingwPORTs). Oh, so we can't rely on 'format c:' ? Cheers, Julien |