From: Cesar S. <ces...@gm...> - 2010-08-25 22:57:11
|
Hello, I've been working lately on the mingw-get XML manifests for gcc 4.5.0 and I think they are currently in a good shape. This includes the missing manifests for the gcc 4.5.0 dependencies as well (mpfr, mpc, pthreads-w32). I'll begin committing them to CVS for review. Keith, do you have any work in progress on this front? I'll gladly merge it in. I would like an opinion on the following: 1) For now, I kept the entries for gcc 3.4.5. Should I remove 3.4.5 altogether? 2) Otherwise, should the gcc package be split into gcc3 and gcc4? 3) Should mingw32-base be renamed to mingw32-gcc? Regards, Cesar |
From: Charles W. <cwi...@us...> - 2010-08-26 01:14:00
|
On 8/25/2010 6:56 PM, Cesar Strauss wrote: > 1) For now, I kept the entries for gcc 3.4.5. Should I remove 3.4.5 > altogether? Depends. Does mingw-get allow you to choose a specific version of a given package (say, "gcc") or does it always give you only the newest version? In that case, we should probably have separate 'mingw32-gcc3' and 'mingw32-gcc4' (or -gcc45?) manifests. We then control the "default" by selecting one or the other to carry the unversioned 'mingw32-gcc' and 'gcc' alias. This brings up another question: does mingw-get support marking two different packages as "conflicting" so that it won't install both at the same time? > 2) Otherwise, should the gcc package be split into gcc3 and gcc4? See above. > 3) Should mingw32-base be renamed to mingw32-gcc? IMO, yes. -- Chuck |
From: Cesar S. <ces...@gm...> - 2010-08-26 02:02:12
|
On 25/8/2010 22:13, Charles Wilson wrote: > On 8/25/2010 6:56 PM, Cesar Strauss wrote: >> 1) For now, I kept the entries for gcc 3.4.5. Should I remove 3.4.5 >> altogether? > > Depends. Does mingw-get allow you to choose a specific version of a > given package (say, "gcc") At the moment, no. On the other hand, the situation is no different from every other package with multiple versions, right now. > or does it always give you only the newest > version? In that case, we should probably have separate 'mingw32-gcc3' > and 'mingw32-gcc4' (or -gcc45?) manifests. We then control the > "default" by selecting one or the other to carry the unversioned > 'mingw32-gcc' and 'gcc' alias. Do you think it is useful to keep the option for installing gcc 3.4.5 from mingw-get? Otherwise, I'll just wipe out any reference for it from the current manifest. Regards, Cesar |
From: Charles W. <cwi...@us...> - 2010-08-26 02:41:12
|
On 8/25/2010 10:01 PM, Cesar Strauss wrote: > On 25/8/2010 22:13, Charles Wilson wrote: >> On 8/25/2010 6:56 PM, Cesar Strauss wrote: >>> 1) For now, I kept the entries for gcc 3.4.5. Should I remove 3.4.5 >>> altogether? >> >> Depends. Does mingw-get allow you to choose a specific version of a >> given package (say, "gcc") > > At the moment, no. On the other hand, the situation is no different from > every other package with multiple versions, right now. Right, but a "complete" installer would have that ability. The question was really just set-up, for: >> or does it always give you only the newest >> version? In that case, we should probably have separate 'mingw32-gcc3' >> and 'mingw32-gcc4' (or -gcc45?) manifests. We then control the >> "default" by selecting one or the other to carry the unversioned >> 'mingw32-gcc' and 'gcc' alias. > > Do you think it is useful to keep the option for installing gcc 3.4.5 > from mingw-get? Yes, I do. It may be old, but it *works*. There are still a few rough spots with the 4.x series (basically having to do with -static-lib* options and user DLLs). > Otherwise, I'll just wipe out any reference for it from > the current manifest. I'd do something like the following: (a) move the <package /> elements of mingw32-base.xml into mingw32-gcc3.xml (and modify the aliases for each package as appropriate, too.) (b) create mingw32-gcc4.xml where the packages are <package name="mingw32-gcc4-core" alias="gcc4-core gcc4 gcc-core gcc"> and similar. This way, 'mingw-get install gcc' DTRT. (c) make mingw32-base define a meta <package /> that installs mingw32-gcc-core (*) mingw32-make (*) the dependency structure will ensure that binutils, mingw-runtime, w32api, and the DLL deps get installed. This way, 'mingw-get install gcc' would install the 4.x version of everything the old Mingw-5.x.x installer would have (assuming you selected only the C compiler). 'mingw-get install gcc g++ gfortran' would work similarly. But, if somebody WANTED to install gcc3, they could do 'mingw-get install gcc3' If they do both: 'mingw-get install gcc3 gcc4' well...don't do that. -- Chuck |
From: Earnie <ea...@us...> - 2010-08-26 11:18:49
|
Charles Wilson wrote: > On 8/25/2010 10:01 PM, Cesar Strauss wrote: >> >> Do you think it is useful to keep the option for installing gcc 3.4.5 >> from mingw-get? > > Yes, I do. It may be old, but it *works*. There are still a few rough > spots with the 4.x series (basically having to do with -static-lib* > options and user DLLs). > Ditto. There will be times when having the previous version is best. Earnie |
From: Keith M. <kei...@us...> - 2010-08-26 19:49:34
Attachments:
mingw32-gcc3.xml
mingw32-gcc4.xml
|
On Thursday 26 August 2010 03:40:32 Charles Wilson wrote: > On 8/25/2010 10:01 PM, Cesar Strauss wrote: > > On 25/8/2010 22:13, Charles Wilson wrote: > >> On 8/25/2010 6:56 PM, Cesar Strauss wrote: > >>> 1) For now, I kept the entries for gcc 3.4.5. Should I remove > >>> 3.4.5 altogether? > >> > >> Depends. Does mingw-get allow you to choose a specific version of > >> a given package (say, "gcc") > > > > At the moment, no. On the other hand, the situation is no different > > from every other package with multiple versions, right now. > > Right, but a "complete" installer would have that ability. Indeed, but Cesar is correct; it doesn't have it yet, but it is on my round tuit list. > The question was really just set-up, for: > >> or does it always give you only the newest > >> version? In that case, we should probably have separate > >> 'mingw32-gcc3' and 'mingw32-gcc4' (or -gcc45?) manifests. We then > >> control the "default" by selecting one or the other to carry the > >> unversioned 'mingw32-gcc' and 'gcc' alias. That's exactly what I have envisioned; I've attached my own versions of mingw32-gcc3.xml (definitive), and mingw32-gcc4.xml (tentative). > > Do you think it is useful to keep the option for installing gcc > > 3.4.5 from mingw-get? > > Yes, I do. It may be old, but it *works*. I agree. Old, it may be, but "if it ain't broke, don't fix it"; I still use it as my production compiler, (all of my mingw-get builds have been compiled with it), and I don't think I am alone. > I'd do something like the following: > > (a) move the <package /> elements of mingw32-base.xml > into mingw32-gcc3.xml (and modify the aliases for each > package as appropriate, too.) Already done, (subject to peer review); I'll commit it to CVS tonight. > (b) create mingw32-gcc4.xml where the packages are > <package name="mingw32-gcc4-core" > alias="gcc4-core gcc4 gcc-core gcc"> > and similar. This way, 'mingw-get install gcc' DTRT. I'll leave it to Cesar to finalise this; use my tentative version as a basis, if you wish Cesar, or just go with your own. > (c) make mingw32-base define a meta <package /> that installs > mingw32-gcc-core (*) > mingw32-make > > (*) the dependency structure will ensure that binutils, > mingw-runtime, w32api, and the DLL deps get installed. We might also consider adding GDB to that; there has been quite a lot of noise asking for it, with no counter argument, AFAICT. > This way, 'mingw-get install gcc' would install the 4.x version of > everything the old Mingw-5.x.x installer would have (assuming you > selected only the C compiler). 'mingw-get install gcc g++ gfortran' > would work similarly. Exactly so. > But, if somebody WANTED to install gcc3, they could do > 'mingw-get install gcc3' As I've written the manifest, it would be mingw-get install gcc-v3 but the principle holds, and we can fine tune it to anything we like, (even supporting both, if we wish). > If they do both: > 'mingw-get install gcc3 gcc4' > well...don't do that. Again, not in any current version, but on my round tuit list, we need some degree of conflict resolution, to guard against this. Also, I'd like to make a variation of it supportable, via the use of alternative system maps, provided the conflicting versions are assigned to distinct sysroots. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-08-30 21:48:00
|
On 8/26/2010 7:55 AM, Keith Marshall wrote: > On Thursday 26 August 2010 03:40:32 Charles Wilson wrote: >> I'd do something like the following: >> >> (a) move the<package /> elements of mingw32-base.xml >> into mingw32-gcc3.xml (and modify the aliases for each >> package as appropriate, too.) > > Already done, (subject to peer review); I'll commit it to CVS tonight. I used Keith's mingw32-gcc4.xml and mingw32-gcc3.xml unchanged in my InnoSetup-based installer. They work fine -- but, of course, the mingw32-gcc4 one required the following: mingw32-gmp.xml mingw32-mpc.xml mingw32-mpfr.xml mingw32-pthreads-w32.xml And, of course, by moving much of the guts from mingw32-base.xml into mingw32-gcc3.xml mingw32-base.xml had to be heavily modified Finally, mingw32-package-list.xml needed a few updated, to include the new manifests. All of these are included in the tarball I posted here: http://article.gmane.org/gmane.comp.gnu.mingw.user/34017 OK to check in? -- at least as an initial stab at it; that way we have *something* and if Keith/Cesar need to update them they can easily do it. This 'share code via mailing list' is bogus; that's what the repo is FOR... And they have all been tested (except for mingw32-gcc3). > We might also consider adding GDB to that; there has been quite a lot of > noise asking for it, with no counter argument, AFAICT. I did. This is what mingw32-base has, in my version: <component class="bin"> <release tarname="mingw32-base-2010082900-mingw32-bin.meta" /> <requires eq="mingw32-gcc-*-mingw32-*-bin.tar" /> <requires eq="mingw32-gcc-*-mingw32-*-lic.tar" /> <requires eq="mingw32-make-*-mingw32-*-bin.tar" /> <requires eq="mingw32-gdb-*-mingw32-*-bin.tar" /> </component> >> This way, 'mingw-get install gcc' would install the 4.x version of Not quite. This /should/ have read 'mingw-get install mingw32-base'. With just 'gcc' you get gcc-core and its requirements (binutils, w32api, etc) but not make or gdb. >> everything the old Mingw-5.x.x installer would have (assuming you >> selected only the C compiler). 'mingw-get install gcc g++ gfortran' >> would work similarly. > > Exactly so. Well...what you really want is: 'mingw-get install base g++ gfortran' I found that if I did 'mingw-get install base gcc g++ gfortran' I get gcc-core-bin PLUS gcc-core-lang, gcc-core-lic, etc. Not sure why, but it is not an issue for the InnoSetup installer. It invokes mingw-get exactly as it needs to, to get exactly what the user selected (e.g. it doesn't double-specify gcc via mingw32-base AND mingw32-gcc). >> If they do both: >> 'mingw-get install gcc3 gcc4' >> well...don't do that. > > Again, not in any current version, but on my round tuit list, we need > some degree of conflict resolution, to guard against this. Also, I'd > like to make a variation of it supportable, via the use of alternative > system maps, provided the conflicting versions are assigned to distinct > sysroots. Well, maybe for the Real Deal mingw-get installer. The Q-n-D InnoSetup beastie is just the bare minimum, so folks will stop whining. -- Chuck |
From: Keith M. <kei...@us...> - 2010-08-30 22:23:15
|
On Monday 30 August 2010 22:47:48 Charles Wilson wrote: > All of these are included in the tarball I posted here: > http://article.gmane.org/gmane.comp.gnu.mingw.user/34017 > > OK to check in? I think so. I haven't inspected them all, but getting something into the repo as a starting point has to be better than just posting here. > -- at least as an initial stab at it; that way we have *something* > and if Keith/Cesar need to update them they can easily do it. This > 'share code via mailing list' is bogus; that's what the repo is > FOR... Agreed. > I found that if I did > > 'mingw-get install base gcc g++ gfortran' > > I get gcc-core-bin PLUS gcc-core-lang, gcc-core-lic, etc. Not sure > why, ... It's because you haven't qualified the package names with any specific component class. Probably not how we want it to work ultimately, but at present this causes mingw-get to select *all* available components of the named package for installation. (More sensible, perhaps, to have it select just the first specified within the package manifest). > but it is not an issue for the InnoSetup installer. No, but some of the XML files included within that tarball will be problematic for mingw-get itself, perhaps not initially, but when the user subsequently invokes `mingw-get update'; see my cautionary note in the mingw-users thread. -- Regards, Keith. |
From: Cesar S. <ces...@gm...> - 2010-08-31 02:33:43
|
On 30/8/2010 18:47, Charles Wilson wrote: > All of these are included in the tarball I posted here: > http://article.gmane.org/gmane.comp.gnu.mingw.user/34017 > > OK to check in? They look great, thanks! Please do check them in. Cesar |
From: Charles W. <cwi...@us...> - 2010-08-31 04:16:33
|
On 8/30/2010 10:33 PM, Cesar Strauss wrote: > On 30/8/2010 18:47, Charles Wilson wrote: > >> All of these are included in the tarball I posted here: >> http://article.gmane.org/gmane.comp.gnu.mingw.user/34017 >> >> OK to check in? > > They look great, thanks! > > Please do check them in. All done. I tested them all locally (build mingw-dist, uncompress into my InnoSetup staging area, build installer, install) and they all seem to work. (I modified gcc4 to use the actual mingwrt package name, rather than relying on the (still missing, pending Cesar's patch) mingw-runtime alias.) However... I did not publish them (.lzma->website) because I can't figure out the mingw-dist build system. Every time I build, it ignores the current contents of issue.log, sets the serialization of EVERYTHING to the current date, and clobbers issue.log with {everything}:2010083100. So...I'll leave the actual push-to-the-web to you guys. Also, it seems that the common/ directory is not built, so in my testing I had to grab that one from the web. I also added to the installer the capability of writing an /etc/fstab if MSYS is installed. And, it now uses the actual 0.1-alpha-3 tarballs from the web, rather than my only self-built-from-CVS version. So...getting closer. Once somebody who actually groks the mingw-dist build system updates the catalogue on the web, I'll roll out the InnoSetup stop-gap for a short testing period, before unleashing it. -- Chuck |
From: Keith M. <kei...@us...> - 2010-08-31 18:59:24
|
On Tuesday 31 August 2010 05:15:33 Charles Wilson wrote: > On 8/30/2010 10:33 PM, Cesar Strauss wrote: > > On 30/8/2010 18:47, Charles Wilson wrote: > >> All of these are included in the tarball I posted here: > >> http://article.gmane.org/gmane.comp.gnu.mingw.user/34017 > >> > >> OK to check in? > > > > They look great, thanks! > > > > Please do check them in. > > All done. I tested them all locally (build mingw-dist, uncompress > into my InnoSetup staging area, build installer, install) and they > all seem to work. Excellent! > (I modified gcc4 to use the actual mingwrt package name, rather than > relying on the (still missing, pending Cesar's patch) mingw-runtime > alias.) Okay. > However... > > I did not publish them (.lzma->website) because I can't figure out > the mingw-dist build system. I still need to figure it out, myself :) It isn't working properly yet, and I have a fair bit of cruft in my working copy which I don't want to check in. > Every time I build, it ignores the > current contents of issue.log, sets the serialization of EVERYTHING > to the current date, and clobbers issue.log with > {everything}:2010083100. Everything? Even if you've already built it before, and not touched its source since? It certainly doesn't do that for me. However, I suspect that what you really mean is that you are missing a step to synchronise between the state represented by issue.log, and the content of your (initially empty of .lzma files) build directory. That's a piece of the jigsaw which I've yet to finalise. > So...I'll leave the actual push-to-the-web to you guys. It's probably best if you leave me to sort out issue.log, (but see below)... > Also, it seems that the common/ directory is not built, It needs to be added to line 31 (in the CVS version) of configure.ac: AC_FOREACH([subdir],[common mingw32 msys], > so in my testing I had to grab that one from the web. > > I also added to the installer the capability of writing an /etc/fstab > if MSYS is installed. And, it now uses the actual 0.1-alpha-3 > tarballs from the web, rather than my only self-built-from-CVS > version. Okay. > So...getting closer. Once somebody who actually groks the mingw-dist > build system updates the catalogue on the web, I'll roll out the > InnoSetup stop-gap for a short testing period, before unleashing it. I'm not going to be able to look at this again, before about the 2nd week in October, (and I may not be around to answer e-mails until then either), so I suggest you and Cesar co-ordinate an interim push of the necessary .xml.lzma files to FRS in the meantime, just to get the ball rolling; I'll take care of synchronising issue.log later, when I can get back to it. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-08-31 19:45:06
|
On 8/31/2010 10:22 AM, Keith Marshall wrote: > Everything? Even if you've already built it before, and not touched its > source since? Well, no -- if I don't clean out the build dir, it does nothing. I didn't try just updating a single file in the src dir, and re-running make. > It certainly doesn't do that for me. However, I suspect > that what you really mean is that you are missing a step to synchronise > between the state represented by issue.log, and the content of your > (initially empty of .lzma files) build directory. That's a piece of > the jigsaw which I've yet to finalise. Right. I guess if I pre-populate my build dir with the .lzma files from the web, then THOSE won't get updated (?)...but everything else will get the current status. I'll give that a try tonight. If it works, then the jigsaw might be as simple as a rule which does exactly that: if the target .lzma doesn't exist, check to see if a copy can be downloaded first. Then, compare the uncompressed copy with the src copy (excluding the serialization strings themselves)... Ugh. This is ugly. I wonder if 'make' is the right tool for this job, or if we need a manifest-maint.exe tool. >> Also, it seems that the common/ directory is not built, > > It needs to be added to line 31 (in the CVS version) of configure.ac: > > AC_FOREACH([subdir],[common mingw32 msys], Are you sure that is all? There are a lot of other places where 'mingw32 msys' appear together in a rule. > I'm not going to be able to look at this again, before about the 2nd > week in October, (and I may not be around to answer e-mails until then > either), so I suggest you and Cesar co-ordinate an interim push of the > necessary .xml.lzma files to FRS in the meantime, just to get the ball > rolling; Well, I certainly don't want to screw up the serialization NUMBERS in the uploaded files, regardless of what happens to issue.log. I reckon that if the newly updated files all have "today's date" but all unchanged files are...left unchanged, then that would work as far as mingw-get is concerned? > I'll take care of synchronising issue.log later, when I can > get back to it. OK. -- Chuck |
From: Charles W. <cwi...@us...> - 2010-08-31 22:27:45
|
On 8/31/2010 3:44 PM, Charles Wilson wrote: > Right. I guess if I pre-populate my build dir with the .lzma files from > the web, then THOSE won't get updated (?)...but everything else will get > the current status. > > I'll give that a try tonight. This worked. But... you and I are stepping on each other's toes *right now*. -- Chuck |
From: Charles W. <cwi...@us...> - 2010-08-31 23:01:45
|
On 8/31/2010 6:26 PM, Charles Wilson wrote: > On 8/31/2010 3:44 PM, Charles Wilson wrote: >> Right. I guess if I pre-populate my build dir with the .lzma files >> from the web, then THOSE won't get updated (?)...but everything else >> will get the current status. >> >> I'll give that a try tonight. > > This worked. But... you and I are stepping on each other's toes > *right now*. OK, it all seems copacetic. I've tested the installer using the .lzma files that are currently on the web. Here it is: http://mingw.cwilson.fastmail.fm/mingw-get-inst-20100831.exe Give it 24 hours, and I'll upload it to mingw.org (and a snapshot of the source code -- which is all of two files: the .iss and the .ico) unless someone squawks. I've put a date stamp on it (rather than a version number like 0.1-alpha-3), because as it is, it carries a snapshot of the xml manifests downloaded -- via 'mingw-get update' as of today's date. -- Chuck |
From: Cesar S. <ces...@gm...> - 2010-09-01 03:42:11
|
On 31/8/2010 20:00, Charles Wilson wrote: > OK, it all seems copacetic. I've tested the installer using the .lzma > files that are currently on the web. Here it is: > > http://mingw.cwilson.fastmail.fm/mingw-get-inst-20100831.exe Working great, thanks! > Give it 24 hours, and I'll upload it to mingw.org (and a snapshot of the > source code -- which is all of two files: the .iss and the .ico) unless > someone squawks. > > I've put a date stamp on it (rather than a version number like > 0.1-alpha-3), because as it is, it carries a snapshot of the xml > manifests downloaded -- via 'mingw-get update' as of today's date. > If I may make a suggestion, you do not need to ship in the installer any manifest besides default.xml or profile.xml. Currently, mingw-get will fetch any missing manifest automatically, even as it fulfills the install request. To test this, I rebuilt the installer without the manifests, and it worked fine (it downloaded all the missing manifests before proceeding with the installation). The benefit is, you get the most up-to-date packages at the time of installation, without needing to keep rebuilding the installer every time a manifest is updated. Regards, Cesar |
From: Charles W. <cwi...@us...> - 2010-09-01 04:03:37
|
On 8/31/2010 11:41 PM, Cesar Strauss wrote: > On 31/8/2010 20:00, Charles Wilson wrote: >> http://mingw.cwilson.fastmail.fm/mingw-get-inst-20100831.exe > > Working great, thanks! > > If I may make a suggestion, you do not need to ship in the installer any > manifest besides default.xml or profile.xml. ... > The benefit is, you get the most up-to-date packages at the time of > installation, without needing to keep rebuilding the installer every > time a manifest is updated. I did it this way, for THIS release, deliberately. I wanted it to install a "snapshot" specifically so that I knew it was fully tested and that future changes to the website wouldn't break it: e.g. if we upload a bogus .xml.lzma or something. I'm being very conservative because mingw-get is so new, AND because Keith will be awol for about six-eight weeks. Once this one is out there and percolating, then I reckon the NEXT release should do something like you suggest. That one won't have a datestamp, but would instead carry mingw-get's own version number. Plus, the installation just created could always be updated by manually running 'mingw-get update; mingw-get install ...' -- Chuck |
From: Keith M. <kei...@us...> - 2010-09-01 18:28:01
|
On Tuesday 31 August 2010 20:44:59 Charles Wilson wrote: > > ... what you really mean is that you are missing a step to > > synchronise between the state represented by issue.log, and the > > content of your (initially empty of .lzma files) build directory. > > That's a piece of the jigsaw which I've yet to finalise. > > Right. I guess if I pre-populate my build dir with the .lzma files > from the web, then THOSE won't get updated (?)...but everything else > will get the current status. Yes, but that would be a kind of ungainly way to do it. > I'll give that a try tonight. > > If it works, ... You later confirmed that it does. > ... then the jigsaw might be as simple as a rule which does > exactly that: if the target .lzma doesn't exist, check to see if a > copy can be downloaded first. Then, compare the uncompressed copy > with the src copy (excluding the serialization strings themselves)... > > Ugh. This is ugly. > > I wonder if 'make' is the right tool for this job, ... IMO yes, make is exactly the right tool for this job. > ... or if we need a manifest-maint.exe tool. I don't think so. I've now got the necessary voodoo working in my local makefile setup; I'll try to get it checked in tonight, then you can make all-sync-offline to synchronise the state of .xml.lzma files in your build directory with the state recorded in your local working copies of issue.log, (in your source directory), or (maybe better) make all-sync[-to-cvs] to do the same, after first making your working issue.log files match the master copies in the CVS repo. > >> Also, it seems that the common/ directory is not built, > > > > It needs to be added to line 31 (in the CVS version) of > > configure.ac: > > > > AC_FOREACH([subdir],[common mingw32 msys], > > Are you sure that is all? Yes, I am 100% sure. > There are a lot of other places where 'mingw32 msys' appear together > in a rule. In Makefiles? Yes, they are all propagated, via AC_SUBST, from this single point of initialisation, when you run configure; (naturally, you must run autoconf on the modified configure.ac first). > > I'm not going to be able to look at this again, before about the > > 2nd week in October, (and I may not be around to answer e-mails > > until then either), so I suggest you and Cesar co-ordinate an > > interim push of the necessary .xml.lzma files to FRS in the > > meantime, just to get the ball rolling; > > Well, I certainly don't want to screw up the serialization NUMBERS in > the uploaded files, regardless of what happens to issue.log. I > reckon that if the newly updated files all have "today's date" but > all unchanged files are...left unchanged, then that would work as far > as mingw-get is concerned? All mingw-get cares about is that the serial number *increases* with each new release; once it has a copy of a manifest, it will ignore any subsequent release which does not have a *greater* serial number, (compared lexically). -- Regards, Keith. |