From: Steven M. <sm...@am...> - 2003-04-30 00:06:06
|
i need to install autoconf under mingw/msys. i have tried to provide m4 and perl (active state) so as to accomplish the autoconf configure but i get the error message m4 not found. does anyone have some detaied directions on how to install autoconf ? thanks Steve |
From: Tripp <el...@ya...> - 2008-04-28 02:31:51
|
hi, on win xp2. msys, mingw 4.2.3 wondering if i can get some help with this. trying to get a more recent autoconf. but nothing doing. i tried 2.60 and 2.61 but on make there's an eternal loop, processes of make and sh go into the hundreds, Making install in . make[57]: Entering directory `/c/test/autoconf-2.6' Making install in bin make[58]: Entering directory `/c/test/autoconf-2.6/bin' make[59]: Entering directory `/c/test/autoconf-2.6' make[59]: Leaving directory `/c/test/autoconf-2.6' make[59]: Entering directory `/c/test/autoconf-2.6/bin' make[60]: Entering directory `/c/test/autoconf-2.6' make[60]: Leaving directory `/c/test/autoconf-2.6' test -z "/usr/local/bin" || /mingw/bin/mkdir -p "/usr/local/bin" /mingw/bin/install -c 'autom4te' '/usr/local/bin/autom4te' /mingw/bin/install -c 'autoconf' '/usr/local/bin/autoconf' /mingw/bin/install -c 'autoheader' '/usr/local/bin/autoheader' /mingw/bin/install -c 'autoreconf' '/usr/local/bin/autoreconf' /mingw/bin/install -c 'ifnames' '/usr/local/bin/ifnames' /mingw/bin/install -c 'autoscan' '/usr/local/bin/autoscan' /mingw/bin/install -c 'autoupdate' '/usr/local/bin/autoupdate' make[59]: Nothing to be done for `install-data-am'. make[59]: Leaving directory `/c/test/autoconf-2.6/bin' make[58]: Leaving directory `/c/test/autoconf-2.6/bin' Making install in . make[58]: Entering directory `/c/test/autoconf-2.6' Making install in bin make[59]: Entering directory `/c/test/autoconf-2.6/bin' make[60]: Entering directory `/c/test/autoconf-2.6' make[60]: Leaving directory `/c/test/autoconf-2.6' make[60]: Entering directory `/c/test/autoconf-2.6/bin' make[61]: Entering directory `/c/test/autoconf-2.6' make[61]: Leaving directory `/c/test/autoconf-2.6' test -z "/usr/local/bin" || /mingw/bin/mkdir -p "/usr/local/bin" /mingw/bin/install -c 'autom4 need to kill by terminating the console. with 2.62, i get this at configure: config.status: WARNING: not linking GNUmakefile to itself and these on make: Makefile:678: warning: overriding commands for target `install' Makefile:574: warning: ignoring old commands for target `install' and then it dies like so: Making all in m4sugar make[3]: Entering directory `/c/test/autoconf-2.6/lib/m4sugar' autom4te_perllibdir='../..'/lib AUTOM4TE_CFG='../../lib/autom4te.cfg' ../../bin/autom4te -B '../..'/lib -B '../..'/lib \ --language=m4sugar \ --freeze \ --output=m4sugar.m4f autom4te: freezing produced output: autom4te: autom4te: autom4te: ....... (repetead many times) autom4te: autom4te: autom4te: autom4te: make[3]: *** [m4sugar.m4f] Error 1 make[3]: Leaving directory `/c/test/autoconf-2.6/lib/m4sugar' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/c/test/autoconf-2.6/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/test/autoconf-2.6' make: *** [all] Error 2 i found something online, can't remember the reasoning but i patched with this: --- bin/autom4te.in 21 Apr 2008 01:33:19 -0000 +++ bin/autom4te.in 22 Apr 2008 01:03:19 -0000 @@ -944,2 +944,3 @@ $result =~ s/#.*\n//g; + $result =~ s/^\r//mg; $result =~ s/^\n//mg; and then make dies like so: autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg' ../bin/autom4te -B '..'/lib -B '..'/lib --language=M4sh ./wrapper.as -o wrapper.in c:\mingw\bin\m4.exe: premature end of frozen file autom4te: /mingw/bin/m4 failed with exit status: 1 make[2]: *** [wrapper.in] Error 1 make[2]: Leaving directory `/c/test/autoconf/tests' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/test/autoconf' make: *** [all] Error 2 using m4 1.4.11 btw but tried a few m4 versions. including a 1.4.7 msys binary i found just so you know, i don;t understand code. ty tripp ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ |
From: Earnie B. <ea...@us...> - 2008-04-28 11:54:35
|
Quoting Tripp <el...@ya...>: > hi, > > on win xp2. > msys, mingw 4.2.3 > > wondering if i can get some help with this. > > trying to get a more recent autoconf. > but nothing doing. > IIRC an environment variable M4=m4 might help. Otherwise see http://www.mingw.org/MinGWiki/index.php/BuildMSYSApplication Earnie |
From: Tripp <el...@ya...> - 2008-04-28 20:29:07
|
--- Earnie Boyd <ea...@us...> wrote: > > Quoting Tripp <el...@ya...>: > > > hi, > > > > on win xp2. > > msys, mingw 4.2.3 > > > > wondering if i can get some help with this. > > > > trying to get a more recent autoconf. > > but nothing doing. > > > > IIRC an environment variable M4=m4 might help. > > Otherwise see > http://www.mingw.org/MinGWiki/index.php/BuildMSYSApplication thanks, i re-tried the msys m4 binary i had and it worked, no install, though, so i had to figure out where things went, but i got that working too. ty tripp ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ |
From: Keith M. <kei...@us...> - 2008-04-29 17:14:34
|
On Monday 28 April 2008 21:28, Tripp wrote: > > > trying to get a more recent autoconf. > > > but nothing doing. > > > > IIRC an environment variable M4=m4 might help. I've never found this to be necessary, myself... > > Otherwise see > > http://www.mingw.org/MinGWiki/index.php/BuildMSYSApplication ...and this may be more information than you want to be bothered with. > thanks, > i re-tried the msys m4 binary i had and it worked, Yes, if you try to replace the MSYS build of m4 with a native build, then you are in trouble. > no install, though, so i had to figure out where things went, > but i got that working too. I've been using autoconf-2.61 since the FSF release was published; it built and installed OOTB, under MSYS, *after* I'd updated the m4-1.4 from the old msysDTK-1.0.1 to the m4-1.4.7-MSYS.tar.bz2 release[1]. All that was required was a $ configure && make && make install Do note that, since autoconf itself is principally a script driven package, and that all the programs invoked by it are MSYS aware, you should *not* specify prefix as a Win32 path. The above installs it to its default location in /usr/local, (equiv. /local with standard MSYS fstab); it should run fine from there, but if you prefer, you may $ configure --prefix=/mingw && make && install Or, if you don't want to be bothered building it yourself, why not just use Chuck's ready made installation kit, for the MSYS-1.0.11 technical preview, (in the supplementary programs category); read his release notes for installation instructions. If you want to try autoconf-2.62, (I haven't gotten around to this yet), then you will need to build it yourself. The `autom4te: freezing produced output' error, which you report, is a sure sign that you are using a native m4 build, rather than the MSYS version; (this also affects building of autoconf-2.60/61); there has been a recent discussion of this very problem, on aut...@gn... Regards, Keith. [1] autoconf release notes say that m4-1.4 is now too old, and while the build didn't actually fail, IIRC, with that version installed, I did note several test suite failures, which were corrected by the newer m4. |
From: Tripp <el...@ya...> - 2008-04-30 14:37:38
|
--- Keith Marshall <kei...@us...> wrote: > On Monday 28 April 2008 21:28, Tripp wrote: > > > > trying to get a more recent autoconf. > > > > but nothing doing. > > > > > > IIRC an environment variable M4=m4 might help. > > I've never found this to be necessary, myself... yeah it detects the path, not had a problem with that. > > thanks, > > i re-tried the msys m4 binary i had and it worked, > > Yes, if you try to replace the MSYS build of m4 with a native build, > then you are in trouble. well i think, it didn't make a difference with 2.60 and 2.61. 1.4.11 or msys 1.4.7 on make they enter an eternal loop. but the files are created. just needed to move them to the right place. > from the old msysDTK-1.0.1 to the m4-1.4.7-MSYS.tar.bz2 release[1]. > All that was required was a > > $ configure && make && make install not for me. in fact nothing seems to be as simple on compilation. > Or, if you don't want to be bothered building it yourself, why not > just > use Chuck's ready made installation kit, for the MSYS-1.0.11 > technical > preview, (in the supplementary programs category); read his release > notes for installation instructions. .... i couldn't be bothered! didn't know there was a ready build. > If you want to try autoconf-2.62, (I haven't gotten around to this > yet), > then you will need to build it yourself. The `autom4te: freezing > produced output' error, which you report, is a sure sign that you are > using a native m4 build, rather than the MSYS version; (this also > affects building of autoconf-2.60/61); there has been a recent > discussion of this very problem, on aut...@gn... yeah, i needed both the patch to autom4te.in, and the msys m4 binary i found. funny thing is that i have 2 build enviroments, one stemming from a tdragon 4.2.3 mingw build, and one from a Tiesi 4.2.3 build. with the tdragon enviroment, replacing m4 with the msys binary still doesn;t work!! with the tiesi enviroment it works, but no, install doesn't work: $ make install Makefile:678: warning: overriding commands for target `install' Makefile:574: warning: ignoring old commands for target `install' /bin/sh /c/test/autoconf/build-aux/missing --run makeinfo --no-headers --no-validate --no-split -o install \ ./doc/install.texi thanks for the detailed response, tripp ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ |
From: Cesar S. <ces...@gm...> - 2008-04-30 14:49:47
|
Tripp wrote: > $ make install > Makefile:678: warning: overriding commands for target `install' > Makefile:574: warning: ignoring old commands for target `install' The makefile seems to be using case sensitive patterns (i.e. install and INSTALL). Please try using "csmake install" instead of "make install". Hope this helps, Cesar |
From: Tripp <el...@ya...> - 2008-04-30 15:12:56
|
--- Cesar Strauss <ces...@gm...> wrote: > Tripp wrote: > > $ make install > > Makefile:678: warning: overriding commands for target `install' > > Makefile:574: warning: ignoring old commands for target `install' > > The makefile seems to be using case sensitive patterns (i.e. install > and > INSTALL). Please try using "csmake install" instead of "make > install". > > Hope this helps, > Cesar thanks it worked a charm. still the mystery of why the in the one build enviroment, it doesn't work with the msys m4 build even though it points to the right path. guess one has to let computers win once in a while. ty tripp ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ |
From: Earnie B. <ea...@us...> - 2008-04-30 19:13:34
|
Quoting Tripp <el...@ya...>: > > --- Cesar Strauss <ces...@gm...> wrote: > >> Tripp wrote: >> > $ make install >> > Makefile:678: warning: overriding commands for target `install' >> > Makefile:574: warning: ignoring old commands for target `install' >> >> The makefile seems to be using case sensitive patterns (i.e. install >> and >> INSTALL). Please try using "csmake install" instead of "make >> install". >> >> Hope this helps, >> Cesar > > thanks it worked a charm. > > still the mystery of why the in the one build enviroment, > it doesn't work with the msys m4 build even though it > points to the right path. > guess one has to let computers win once in a while. > Yet another reason why csmake should be the default make for MSYS. Earnie |
From: Keith M. <kei...@us...> - 2008-04-30 20:29:15
|
On Wednesday 30 April 2008 20:13, Earnie Boyd wrote: > Yet another reason why csmake should be the default make for MSYS. Sorry, but with respect, I disagree. Makefiles which rely on case sensitive discrimination of pseudo-targets are BROKEN, BROKEN, BROKEN; *they* should be fixed. Don't smack the child, when it is the parent who is at fault. We've had this argument before, and I *don't* want to to reopen it. Fix the cause of the problem, not the symptom. I've explained at length why your argument leads to REALLY badly broken makefiles. You've offered me a proposed two rule variation on a single pattern rule, which csmake cannot handle. You suggest that this proposed rule pair circumvents the problem I outlined; I can give you 7.3787e+19 reasons why your proposed solution is ineffective, (and that's a naive estimate based on an 8.3 file name, with only alphanumerics plus the underscore and hyphen permitted in file names, and assuming the case of the target, but not the prerequisite, is ALWAYS predictable). You are welcome to assign csmake as *your* default make tool; for me, that will *never* be an acceptable configuration. It is really easy to choose distinct target names, so that a make which properly respects the case *insensitive* property of the file system isn't confused; it is borderline impossible to correct the mayhem which ensues, when make assumes it can pretend that case sensitive distinctions are somehow magically possible on a case insensitive file system. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2008-05-02 14:39:04
|
Quoting Keith Marshall <kei...@us...>: > On Wednesday 30 April 2008 20:13, Earnie Boyd wrote: >> Yet another reason why csmake should be the default make for MSYS. > > Sorry, but with respect, I disagree. Makefiles which rely on case > sensitive discrimination of pseudo-targets are BROKEN, BROKEN, BROKEN; > *they* should be fixed. Don't smack the child, when it is the parent > who is at fault. > What about other tools like GCC that use case of the filename to do something different; are they broken even though documented? Case preservation and thus case sensitive patterns are a must and not something to be tossed out because you believe that case insensitiveness is better. Earnie |
From: Keith M. <kei...@us...> - 2008-04-30 21:57:04
|
On Wednesday 30 April 2008 21:31, Keith Marshall wrote: > I can give you 7.3787e+19 reasons > why your proposed solution is ineffective Correction; in haste, I miscalculated. The reality is even worse; csmake would require 1.021456e+27 distinct rules, to replace just _one_ simple pattern rule of the form: %.TXT: %.APP ; dostool $< where `dostool is a legacy MS-DOS tool to generate *.TXT files, (always named in upper case, because that's what MS-DOS tools do), from *.APP source files, where the case of the source file name is unpredictable, and assuming only [-A-Z_a-z0-9] are allowed in the source file name. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2008-05-02 02:58:45
|
Quoting Keith Marshall <kei...@us...>: > On Wednesday 30 April 2008 21:31, Keith Marshall wrote: >> I can give you 7.3787e+19 reasons >> why your proposed solution is ineffective > > Correction; in haste, I miscalculated. The reality is even worse; > csmake would require 1.021456e+27 distinct rules, to replace just _one_ > simple pattern rule of the form: > > %.TXT: %.APP ; dostool $< > Wouldn't just one do? %.TXT: %.app ; dostool $< Well, unless you want to really support such possible nonsense as myfile.App and myfile.APp and myfile.ApP, etc. > where `dostool is a legacy MS-DOS tool to generate *.TXT files, (always > named in upper case, because that's what MS-DOS tools do), from *.APP > source files, where the case of the source file name is unpredictable, > and assuming only [-A-Z_a-z0-9] are allowed in the source file name. > Simple, if it's legacy code then the file names on the file system must match the legacy system names, even in case. Case sensitive patterns on windows file systems is a must, the file system may actually support case sensitivity but even those that don't support case preservation. The real issue seems to be that the files from the legacy system could be named with lowercase because it is natural even though it should not be. Again if you're supporting a legacy system then the files must be named even in case as the legacy system expects it and not as the new system might make the case. Earnie |
From: Dave K. <dav...@ar...> - 2008-04-30 23:42:26
|
Keith Marshall wrote on 30 April 2008 22:59: > On Wednesday 30 April 2008 21:31, Keith Marshall wrote: >> I can give you 7.3787e+19 reasons >> why your proposed solution is ineffective > > Correction; in haste, I miscalculated. The reality is even worse; > csmake would require 1.021456e+27 distinct rules, to replace just _one_ > simple pattern rule of the form: > > %.TXT: %.APP ; dostool $< I think that's rather a red herring - after all, that's not a pseudo-target, which is what you were talking about originally. If MinGW wants to be POSIX-alike, it should do what POSIX does, and treat them as case-sensitive. On the other hand, if MinGW wants to be like Windows, it should do what NMAKE does, and treat them as case-sensitive. As to respecting the properties of the filing system: Some filing systems are case-sensitive. Some are not. Even on Windows, this is the case. How do you decide on which filing system (at which drive letter and path) the non-existent file that doesn't ever get created corresponding to the phony target lives (or rather, doesn't live) on? cheers, DaveK -- Can't think of a witty .sigline today.... |
From: Keith M. <kei...@us...> - 2008-05-01 06:57:19
|
On Thursday 01 May 2008 00:42, Dave Korn wrote: > >> I can give you 7.3787e+19 reasons > >> why your proposed solution is ineffective > > > > Correction; in haste, I miscalculated. The reality is even worse; > > csmake would require 1.021456e+27 distinct rules, to replace just > > _one_ simple pattern rule of the form: > > > > %.TXT: %.APP ; dostool $< > > I think that's rather a red herring Again with respect, it is not; it is an example from a real world application, which didn't work, and was impossible to fix with the old make-3.79 in earlier versions of MSYS, yet which works perfectly with Chuck's newer make-3.81. (csmake reproduces the old -- broken IMO -- behaviour of MSYS's make-3.79). > - after all, that's not a > pseudo-target, which is what you were talking about originally. Doesn't make a pin of difference. GNU make treats real and pseudo targets alike; build it with the --enable-case-insensitive-file-system option, (which IMO is how it should be built for MS-Windows), and both real and pseudo targets become case insensitive. > If MinGW wants to be POSIX-alike, it should do what POSIX does, and > treat them as case-sensitive. Can't have it both ways. MinGW does *not* make any pretense to being POSIX-alike; quite the opposite, in fact. It keeps recurring on this list; MinGW is *not* POSIX, because MS-Windows is not POSIX; if you want POSIX-alike, use Cygwin. > On the other hand, if MinGW wants to be like Windows, it should do > what NMAKE does, and treat them as case-sensitive. Yes, exactly; this is the only sane correct behaviour, IMO. > As to respecting the properties of the filing system: > > Some filing systems are case-sensitive. Some are not. Even on > Windows, this is the case. Yes. This is a limitation of GNU make itself; it either considers *all* addressable file systems as case sensitive or as case insensitive. It does not have any provision for dealing with hybrid networks, where some hosts serve a case sensitive file system, while others may be case insensitive; it adopts an unsatisfactory compromise, which is decided at build time for make itself, and that is best based on the localhost file system properties. > How do you decide on which filing system (at which drive letter and > path) the non-existent file that doesn't ever get created > corresponding to the phony target lives (or rather, doesn't live) on? How do you, (or rather, how does make), know whether *any* target is real or pseudo? Sure, GNU make has the special `PHONY' target, to declare pseudo-targets, but that's decidedly non-portable. Write your makefile to rely on this feature, and it is broken for any make which doesn't support the GNU make idiom, if any file named to match any of your pseudo-targets, (including a file called PHONY itself), ever appears in your build directory, with a newer timestamp than its prerequisites. Regards, Keith. |
From: Yongwei W. <wuy...@gm...> - 2008-05-01 07:26:54
|
2008/5/1 Keith Marshall <kei...@us...>: > > How do you decide on which filing system (at which drive letter and > > path) the non-existent file that doesn't ever get created > > corresponding to the phony target lives (or rather, doesn't live) on? > > How do you, (or rather, how does make), know whether *any* target is > real or pseudo? Sure, GNU make has the special `PHONY' target, to > declare pseudo-targets, but that's decidedly non-portable. Write your > makefile to rely on this feature, and it is broken for any make which > doesn't support the GNU make idiom, if any file named to match any of > your pseudo-targets, (including a file called PHONY itself), ever > appears in your build directory, with a newer timestamp than its > prerequisites. Portable to what? AFAIK, there are two `standards' for Make: the GNU standard, and the POSIX standard. Also, if one checks big projects, one will often see separate makefiles for different flavours of make, because advanced features of make are never portable. I do not see your point. In fact, the current behaviour of MinGW Make 3.81 definitely breaks makefiles designed for POSIX/UNIX/Linux systems, where cases matter. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Keith M. <kei...@us...> - 2008-05-01 10:57:59
|
On Thursday 01 May 2008 08:26, Yongwei Wu wrote: > Portable to what? AFAIK, there are two `standards' for Make: the GNU > standard, and the POSIX standard. Also, if one checks big projects, > one will often see separate makefiles for different flavours of make, > because advanced features of make are never portable. I do not see > your point. The entire ethos of the autotools is to focus on creating scripts and makefiles which are as portable as practicably possible, to the widest possible spectrum of hosts, without reliance on *any* particular flavour of shell or make. Using case sensitive only distinctions in makefile rules violates this ethos, even with GNU make, for if you build it with the --enable-case-insensitive-file-system option, (which AFAIK, and correctly IMO, is the way the GNU make folks themselves recommend for use on Win32). This present discussion arose out of a problem in building autoconf, which uses an automake generated Makefile; it relies on being able to discriminate `install' and `INSTALL' as independent targets, which is impossible even for GNU make, when it is configured for a case insensitive file system. IMO, this violates the automake ethos, and is therefore a reportable bug; I fully intend to report it as such, when I have verified it for myself. > In fact, the current behaviour of MinGW Make 3.81 definitely breaks > makefiles designed for POSIX/UNIX/Linux systems, where cases matter. It doesn't, if the authors of those makefiles take appropriate care to avoid the pitfall of independent targets, which can be distinguished only with regard to case in their names; that's an easy objective to accomplish. Yongwei, I have a great deal of respect for both your opinion, and for Earnie's, but in this case you both seem to be blinkered by the not so very useful case preserving feature of the Win32 file system. Case preserving != case insensitive, and when you try to pretend otherwise, you break a case which is very much more difficult, if not actually impossible to fix, just to support an easily avoided usage, (IMO a *broken* usage), which isn't ever *really* necessary. Sorry, but I just don't see any rationale in that choice. Sure, you have your reasons for wanting this feature, and even though I don't agree with you, I respect your right to a different choice; I support that right by providing csmake, and you are free to replace make with this, if you so prefer, but it remains my contention that the existing configuration of the distributed make-3.81 is the correct choice for general use. Additionally, while the existing make-3.81 release of mingw32-make is entirely consistent with the current MSYS make-3.81, and we don't offer a corresponding mingw32-csmake, there is nothing to stop you building that for yourself; it builds OOTB, from current GNU sources, without patches. Right. I said I didn't want to reopen the old argument, yet here I am discussing it again. My opinion on the matter remains unchanged, so there really doesn't seem to be much more to be said. As I've said, I fully respect your right to hold a different opinion, and both cases are, IMO, adequately catered for. Let us simply agree to differ. Regards, Keith. |
From: Cesar S. <ces...@gm...> - 2008-05-01 13:11:43
|
Keith Marshall wrote: > This present discussion arose out of a problem in building autoconf, > which uses an automake generated Makefile; it relies on being able to > discriminate `install' and `INSTALL' as independent targets, which is > impossible even for GNU make, when it is configured for a case > insensitive file system. IMO, this violates the automake ethos, and is > therefore a reportable bug; I fully intend to report it as such, when I > have verified it for myself. I don't think Automake is the culprit, here. Autoconf is just unusual in that it autogenerates INSTALL from doc/install.texi === Begin autoconf's Makefile.am snippet === $(srcdir)/INSTALL: $(top_srcdir)/doc/install.texi $(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -o $@ \ $(top_srcdir)/doc/install.texi === End autoconf's Makefile.am snippet === Projects that do not autogenerate INSTALL (99% of them, I guess) will not have the "INSTALL" target. Regards, Cesar |
From: Keith M. <kei...@us...> - 2008-05-01 13:43:44
|
On Thursday 01 May 2008 14:11, Cesar Strauss wrote: > I don't think Automake is the culprit, here. No, I've been coming to that conclusion myself; having looked through autoconf-2.61 sources, I couldn't see any instance of an `INSTALL' target. > Autoconf is just unusual > in that it autogenerates INSTALL from doc/install.texi > > === Begin autoconf's Makefile.am snippet === > > $(srcdir)/INSTALL: $(top_srcdir)/doc/install.texi > $(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -o $@ \ > $(top_srcdir)/doc/install.texi > > === End autoconf's Makefile.am snippet === But that's not a bare `INSTALL' target; it's an explicit file target, qualified by a directory path. Maybe it's a limitation of (GNU) make, that it cannot discriminate this from a similarly named, but otherwise unqualified by any directory name, pseudo-target. If that is so, then there would seem to be a case for autoconf to devise a more robust stratagem, for building its $(srcdir)/INSTALL target. > Projects that do not autogenerate INSTALL (99% of them, I guess) will > not have the "INSTALL" target. I'd guess at even greater than 99%. :-) Thanks for this insight, Cesar. Regards, Keith. |
From: Keith M. <kei...@us...> - 2008-05-01 15:31:09
|
On Thursday 01 May 2008 14:45, Keith Marshall wrote: > > Autoconf is just unusual > > in that it autogenerates INSTALL from doc/install.texi > > > > === Begin autoconf's Makefile.am snippet === > > > > $(srcdir)/INSTALL: $(top_srcdir)/doc/install.texi > > $(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -o $@ \ > > $(top_srcdir)/doc/install.texi > > > > === End autoconf's Makefile.am snippet === > > But that's not a bare `INSTALL' target; it's an explicit file target, > qualified by a directory path. Maybe it's a limitation of (GNU) > make, that it cannot discriminate this from a similarly named, but > otherwise unqualified by any directory name, pseudo-target. > > If that is so, then there would seem to be a case for autoconf to > devise a more robust stratagem, for building its $(srcdir)/INSTALL > target. However, with make-3.81 on my GNU/Linux box, this Makefile:-- $cat Makefile srcdir = .. VPATH = $(srcdir) foodir = $(srcdir)/foo bardir = $(srcdir)/bar all: $(foodir)/install $(bardir)/install dirs: $(foodir) $(bardir) $(foodir) $(bardir): mkdir -p $@ $(foodir)/install $(bardir)/install: dirs echo $@ > $@ install: echo installing ... doesn't seem to have the slightest problem distinguishing the three separate `install' targets[1]:-- $ make mkdir -p ../foo mkdir -p ../bar echo ../foo/install > ../foo/install echo ../bar/install > ../bar/install $ make install echo installing ... installing ... so I don't know what the deal is for MSYS make-3.81, with this apparent `install' vs. $(srcdir)/INSTALL contention we've been discussing. Yes, there does seem to be a problem, but I don't have access to a Win32 box at present, to investigate it further. Regards, Keith. [*] The above Makefile does, however, have a problem if either a `foo' or a `bar' directory exists in the *parent* of $(srcdir):-- $ rm -rf ../{foo,bar} $ mv ../../foobar ../../foo $ make mkdir -p ../bar echo ../foo/install > ../foo/install /bin/sh: ../foo/install: No such file or directory make: *** [../foo/install] Error 1 Notice how the existence of ../../foo causes make to believe that ../foo already exists, so it isn't remade, but it doesn't then associate that same ../../foo directory with the $(foodir)/install target. This would seem to be related to VPATH resolution, since commenting out the VPATH definition makes the problem go away. |
From: Earnie B. <ea...@us...> - 2008-05-02 14:30:36
|
Quoting Keith Marshall <kei...@us...>: > This would > seem to be related to VPATH resolution, since commenting out the VPATH > definition makes the problem go away. > http://make.paulandlesley.org/vpath.html Earnie |
From: Yongwei W. <wuy...@gm...> - 2008-05-02 12:31:34
|
2008/5/1 Keith Marshall <kei...@us...>: > On Thursday 01 May 2008 08:26, Yongwei Wu wrote: > > Portable to what? AFAIK, there are two `standards' for Make: the GNU > > standard, and the POSIX standard. Also, if one checks big projects, > > one will often see separate makefiles for different flavours of make, > > because advanced features of make are never portable. I do not see > > your point. > > The entire ethos of the autotools is to focus on creating scripts and > makefiles which are as portable as practicably possible, to the widest > possible spectrum of hosts, without reliance on *any* particular > flavour of shell or make. Using case sensitive only distinctions in > makefile rules violates this ethos, even with GNU make, for if you > build it with the --enable-case-insensitive-file-system option, (which > AFAIK, and correctly IMO, is the way the GNU make folks themselves > recommend for use on Win32). This is not my topic, since I do not use and do not like autotools. However, do you have real examples that people use *GNU* autotools with *non-GNU* make? When I talked about `separate makefiles', I meant something like the 57 .mak files in STLport-4.6.2. > This present discussion arose out of a problem in building autoconf, > which uses an automake generated Makefile; it relies on being able to > discriminate `install' and `INSTALL' as independent targets, which is > impossible even for GNU make, when it is configured for a case > insensitive file system. IMO, this violates the automake ethos, and is > therefore a reportable bug; I fully intend to report it as such, when I > have verified it for myself. > > In fact, the current behaviour of MinGW Make 3.81 definitely breaks > > makefiles designed for POSIX/UNIX/Linux systems, where cases matter. > > It doesn't, if the authors of those makefiles take appropriate care to > avoid the pitfall of independent targets, which can be distinguished > only with regard to case in their names; that's an easy objective to > accomplish. Not if they did not think about it at all. I did not intend to persuade you--unlikely to succeed, in my opinion--I just want to point out that there are different ways of trade-off. > Yongwei, I have a great deal of respect for both your opinion, and for > Earnie's, but in this case you both seem to be blinkered by the not so > very useful case preserving feature of the Win32 file system. Case > preserving != case insensitive, and when you try to pretend otherwise, > you break a case which is very much more difficult, if not actually > impossible to fix, just to support an easily avoided usage, (IMO a > *broken* usage), which isn't ever *really* necessary. Sorry, but I > just don't see any rationale in that choice. Again, I want to say I did not intend to persuade you. I just wanted to express my opinions. In fact, I have the similar feelings about you. The case-sensitiveness discussion of make is the only case I remember about your being a little `unreasonable'. I guess it was because we experienced different bites from it. If my memory serves me correct, you were biten once by the case-insensitive file system; and I was biten by the new case-insensitive make behaviour. MinGW make 3.79 (again, not MSYS, which seems to be your impression) worked very well for me. And I use make for a slightly different purpose from you. I work mostly on Windows, and when I use GCC, it is mostly for free software. The current official version of make cannot prevent me from making a mistake in case (if what happend to you once happend to me)--I would rather check for errors myself than have other people complain that the source tarball does not work on their systems. I am sure many other people use GCC in a similar way. > Sure, you have your reasons for wanting this feature, and even though I > don't agree with you, I respect your right to a different choice; I > support that right by providing csmake, and you are free to replace > make with this, if you so prefer, but it remains my contention that the > existing configuration of the distributed make-3.81 is the correct > choice for general use. How about a vote? > Additionally, while the existing make-3.81 release of mingw32-make is > entirely consistent with the current MSYS make-3.81, and we don't offer > a corresponding mingw32-csmake, there is nothing to stop you building > that for yourself; it builds OOTB, from current GNU sources, without > patches. This is what I use. However, it only adds to my burden, since I do not want my Makefile to work only for myself. I now often test with different versions of make now. > Right. I said I didn't want to reopen the old argument, yet here I am > discussing it again. My opinion on the matter remains unchanged, so > there really doesn't seem to be much more to be said. As I've said, I > fully respect your right to hold a different opinion, and both cases > are, IMO, adequately catered for. Let us simply agree to differ. It is the third time I say I did not intend to persuade you. The only point I want to add is that the official behaviour should be decided by the MinGW community how they use MinGW tools, but not by individuals like you and me. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Earnie B. <ea...@us...> - 2008-05-02 13:55:42
|
Quoting Yongwei Wu <wuy...@gm...>: > 2008/5/1 Keith Marshall <kei...@us...>: >> On Thursday 01 May 2008 08:26, Yongwei Wu wrote: >> > Portable to what? AFAIK, there are two `standards' for Make: the GNU >> > standard, and the POSIX standard. Also, if one checks big projects, >> > one will often see separate makefiles for different flavours of make, >> > because advanced features of make are never portable. I do not see >> > your point. >> >> The entire ethos of the autotools is to focus on creating scripts and >> makefiles which are as portable as practicably possible, to the widest >> possible spectrum of hosts, without reliance on *any* particular >> flavour of shell or make. Using case sensitive only distinctions in >> makefile rules violates this ethos, even with GNU make, for if you >> build it with the --enable-case-insensitive-file-system option, (which >> AFAIK, and correctly IMO, is the way the GNU make folks themselves >> recommend for use on Win32). > > This is not my topic, since I do not use and do not like autotools. > However, do you have real examples that people use *GNU* autotools > with *non-GNU* make? > When I was active years ago on those lists there were those adding support for the likes of CL and LIB. Insane, maybe, but think WINE on Linux and maybe not. Earnie |
From: Earnie B. <ea...@us...> - 2008-05-02 14:11:15
|
Quoting Yongwei Wu <wuy...@gm...>: >> Sure, you have your reasons for wanting this feature, and even though I >> don't agree with you, I respect your right to a different choice; I >> support that right by providing csmake, and you are free to replace >> make with this, if you so prefer, but it remains my contention that the >> existing configuration of the distributed make-3.81 is the correct >> choice for general use. > > How about a vote? > Case sensitive patterns for MinGW make are a must because the MinGW GCC supports file extensions by case as special; file.s isn't the same as file.S to GCC. +1 for case sensitive patterns. Earnie |
From: Keith M. <kei...@us...> - 2008-05-09 20:17:35
|
On Wednesday 30 April 2008 15:49, Cesar Strauss wrote: > Tripp wrote: > > $ make install > > Makefile:678: warning: overriding commands for target `install' > > Makefile:574: warning: ignoring old commands for target `install' > > The makefile seems to be using case sensitive patterns (i.e. install > and INSTALL). FWIW, I got back to the office this week, and gave autoconf-2.62 a try, building from pristine FSF source, using MSYS-1.0.11. I did *not* do this... > Please try using "csmake install" instead of "make install". ...yet I had no problem in either building or installing, and after fixing a minor issue in the testsuite, (and seven hours of run time), I was also able to run that with complete success. So, why did I fail to reproduce Tripp's failure? Here's what I did:-- 1) Download and extract ftp.gnu.org/gnu/autoconf/autoconf-2.62.tar.bz2 2) mkdir -p build/autoconf-2.62 3) cd build/autoconf-2.62 4) ../../autoconf-2.62/configure 5) make 6) make install This all completed without any problem whatsoever, so I guessed that maybe Tripp did his build in the source directory, (something I never do, if it is avoidable), and sure enough, if I do that, then I *can* reproduce his problem. So, it seems that this Makefile rule... > $(srcdir)/INSTALL: $(top_srcdir)/doc/install.texi > $(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -o $@ \ > $(top_srcdir)/doc/install.texi ...found at Makefile line 677, (with commands starting at line 678), conflicts with this one... | install: $(BUILT_SOURCES) | $(MAKE) $(AM_MAKEFLAGS) install-recursive ...(found at lines 573/574), if, and only if, make is (correctly, IMO) configured to respect the fundamentally case-insensitive nature of the Win32 file system, *and* $(srcdir) is identically equal to `.', (as will be the case when building within the source directory). This issue may be resolved by replacing each of the three references to `$(srcdir)/INSTALL', in the Makefile, by `$(abs_srcdir)/INSTALL'. IMO, this is a more technically appropriate solution to the problem, than the symptomatic workaround of using csmake in preference to make, so I am `putting my money where my mouth is', and I have filed a bug report, and proposed patch, with bug...@gn... accordingly. Regards, Keith. |