From: John C. <jo...@st...> - 2002-09-14 10:15:46
|
I have noticed that the two versions of make (mingw-make packaged with MinGW-2.0.0-3 and the one with msys 1.0.8 snapshot) set $(MAKE) differently. The mingw one sets it to a windows path (e.g. D:/mingw/bin/mingw-make.exe) and the msys on to something like /bin/make. I am trying to get make to build OOB in msys by running configure && make, and would like it to choose what to report $(MAKE) as depending on what environment it is in. Make itself checks what type of shell it is running - it runs a simple check to see if the shell contains 'sh' and sets unixy_shell. Therefore, if I knew the value of this, I could change the setting of $(MAKE) at run-time. What I am asking is how has the msys version of make been altered from the default sources to report the location of make in a unixy manner (as my build from sources uses the windows one)? Thanks in advance, John. |
From: Earnie B. <ear...@ya...> - 2002-09-14 12:04:22
|
John Cronin wrote: > > I have noticed that the two versions of make (mingw-make packaged with > MinGW-2.0.0-3 and the one with msys 1.0.8 snapshot) set $(MAKE) differently. > The mingw one sets it to a windows path (e.g. D:/mingw/bin/mingw-make.exe) and > the msys on to something like /bin/make. I am trying to get make to build OOB > in msys by running configure && make, and would like it to choose what to report > $(MAKE) as depending on what environment it is in. > > Make itself checks what type of shell it is running - it runs a simple check to > see if the shell contains 'sh' and sets unixy_shell. Therefore, if I knew the > value of this, I could change the setting of $(MAKE) at run-time. > > What I am asking is how has the msys version of make been altered from the > default sources to report the location of make in a unixy manner (as my build > from sources uses the windows one)? > Use the source Luke. CVS co msys/packages/make Earnie. |
From: John C. <jo...@st...> - 2002-09-14 17:30:17
|
-----Original Message----- From: min...@li... [mailto:min...@li...]On Behalf Of Earnie Boyd Sent: 14 September 2002 13:05 To: John Cronin Cc: min...@li... Subject: Re: [Mingw-msys] Differences between mingw-make and msys' make >John Cronin wrote: >> >> I have noticed that the two versions of make (mingw-make packaged with >> MinGW-2.0.0-3 and the one with msys 1.0.8 snapshot) set $(MAKE) differently. >> The mingw one sets it to a windows path (e.g. D:/mingw/bin/mingw-make.exe) and >> the msys on to something like /bin/make. I am trying to get make to build OOB >> in msys by running configure && make, and would like it to choose what to report >> $(MAKE) as depending on what environment it is in. >> >> Make itself checks what type of shell it is running - it runs a simple check to >> see if the shell contains 'sh' and sets unixy_shell. Therefore, if I knew the >> value of this, I could change the setting of $(MAKE) at run-time. >> >> What I am asking is how has the msys version of make been altered from the >> default sources to report the location of make in a unixy manner (as my build >> from sources uses the windows one)? >> > >Use the source Luke. CVS co msys/packages/make > >Earnie. Yeah, thanks Earnie. Didn't think of looking there (doh). Now problem is, that tomorrow I'm moving and won't have internet access (well will, but will be slow and away from my development machine). Therefore, I won't be able to keep working away at make, and if anyone else is interested, they have my blessing. Current status report: I have a patch for make-3.80rc2 to allow it to configure && make OOB on msys and mingw (without breaking building on anything else). What you get is a windows32 build (ie it expects to be run from command.com and outputs windows style paths etc. - pretty much like mingw-make). What needs to be done is: 1) Submitting all changes in this patch (minus two - the hash.h one and the loadavg one - they have already been fixed in CVS) to the current make maintainer (Paul Smith). In fact he already has all apart from the glob subdirectory Makefile.am one. And I'm sure he doesn't need to know about changes to configure and Makefile.in. 2) Getting the changes from mingw CVS msys/packages/make version 1.2 into the source, and having them 1. not break anything! and 2. only activate when make is _run_ on msys, ie not from command.com. The patch: diff -Naurd make-3.80rc2/Makefile.am make-3.80rc2-jc/Makefile.am --- make-3.80rc2/Makefile.am Thu Jul 11 07:38:57 2002 +++ make-3.80rc2-jc/Makefile.am Fri Sep 13 16:43:19 2002 @@ -13,24 +13,38 @@ remote = remote-stub.c endif +if MINGW + w32_include = -I$(top_srcdir)/w32/include + w32_sources = w32/pathstuff.c w32/compat/dirent.c w32/subproc/sub_proc.c \ + w32/subproc/w32err.c + w32_misc = w32misc.o +endif + make_SOURCES = ar.c arscan.c commands.c default.c dir.c expand.c file.c \ function.c getopt.c getopt1.c implicit.c job.c main.c \ misc.c read.c remake.c $(remote) rule.c signame.c \ - variable.c version.c vpath.c hash.c + variable.c version.c vpath.c hash.c $(w32_sources) EXTRA_make_SOURCES = remote-stub.c remote-cstms.c noinst_HEADERS = commands.h dep.h filedef.h job.h make.h rule.h variable.h \ debug.h getopt.h gettext.h hash.h -make_LDADD = @LIBOBJS@ @ALLOCA@ $(GLOBLIB) @GETLOADAVG_LIBS@ @LIBINTL@ +make_LDADD = @LIBOBJS@ @ALLOCA@ $(w32_misc) $(GLOBLIB) @GETLOADAVG_LIBS@ \ + @LIBINTL@ man_MANS = make.1 DEFS = -DLOCALEDIR=\"$(localedir)\" -DLIBDIR=\"$(libdir)\" -DINCLUDEDIR=\"$(includedir)\" @DEFS@ -AM_CPPFLAGS = $(GLOBINC) +AM_CPPFLAGS = $(GLOBINC) $(w32_include) +# How to build w32/subproc/misc.c +# We need this to build it to w32misc.o (there is already a misc.c which builds +# to misc.o in the toplevel directory) + +w32misc.o: + $(COMPILE) -c -o w32misc.o w32/subproc/misc.c # Extra stuff to include in the distribution. # Note we need all the glob stuff here, rather than in glob/Makefile.am, @@ -113,7 +127,7 @@ .PHONY: check-loadavg check-regression -check-loadavg: loadavg +check-loadavg: loadavg$(EXEEXT) @echo The system uptime program believes the load average to be: -uptime @echo The GNU load average checking code thinks: @@ -121,9 +135,11 @@ # The loadavg function is invoked during "make check" to test getloadavg. noinst_PROGRAMS = loadavg -loadavg_SOURCES = getloadavg.c +loadavg_SOURCES = loadavg.c loadavg_CFLAGS = -DTEST loadavg_LDADD = @GETLOADAVG_LIBS@ +loadavg.c: + cp $(srcdir)/getloadavg.c loadavg.c # > check-regression # diff -Naurd make-3.80rc2/Makefile.in make-3.80rc2-jc/Makefile.in --- make-3.80rc2/Makefile.in Tue Sep 10 22:16:47 2002 +++ make-3.80rc2-jc/Makefile.in Fri Sep 13 16:43:28 2002 @@ -119,10 +119,16 @@ @USE_CUSTOMS_TRUE@remote = remote-cstms.c @USE_CUSTOMS_FALSE@remote = remote-stub.c +@MINGW_TRUE@w32_include = -I$(top_srcdir)/w32/include +@MINGW_TRUE@w32_sources = w32/pathstuff.c w32/compat/dirent.c w32/subproc/sub_proc.c \ +@MINGW_TRUE@ w32/subproc/w32err.c + +@MINGW_TRUE@w32_misc = w32misc.o + make_SOURCES = ar.c arscan.c commands.c default.c dir.c expand.c file.c \ function.c getopt.c getopt1.c implicit.c job.c main.c \ misc.c read.c remake.c $(remote) rule.c signame.c \ - variable.c version.c vpath.c hash.c + variable.c version.c vpath.c hash.c $(w32_sources) EXTRA_make_SOURCES = remote-stub.c remote-cstms.c @@ -131,13 +137,15 @@ debug.h getopt.h gettext.h hash.h -make_LDADD = @LIBOBJS@ @ALLOCA@ $(GLOBLIB) @GETLOADAVG_LIBS@ @LIBINTL@ +make_LDADD = @LIBOBJS@ @ALLOCA@ $(w32_misc) $(GLOBLIB) @GETLOADAVG_LIBS@ \ + @LIBINTL@ + man_MANS = make.1 DEFS = -DLOCALEDIR=\"$(localedir)\" -DLIBDIR=\"$(libdir)\" -DINCLUDEDIR=\"$(includedir)\" @DEFS@ -AM_CPPFLAGS = $(GLOBINC) +AM_CPPFLAGS = $(GLOBINC) $(w32_include) # Extra stuff to include in the distribution. @@ -176,7 +184,7 @@ # The loadavg function is invoked during "make check" to test getloadavg. noinst_PROGRAMS = loadavg -loadavg_SOURCES = getloadavg.c +loadavg_SOURCES = loadavg.c loadavg_CFLAGS = -DTEST loadavg_LDADD = @GETLOADAVG_LIBS@ @@ -196,21 +204,24 @@ noinst_PROGRAMS = loadavg$(EXEEXT) PROGRAMS = $(bin_PROGRAMS) $(noinst_PROGRAMS) -am_loadavg_OBJECTS = loadavg-getloadavg.$(OBJEXT) +am_loadavg_OBJECTS = loadavg-loadavg.$(OBJEXT) loadavg_OBJECTS = $(am_loadavg_OBJECTS) loadavg_DEPENDENCIES = loadavg_LDFLAGS = @USE_CUSTOMS_TRUE@am__objects_1 = remote-cstms.$(OBJEXT) @USE_CUSTOMS_FALSE@am__objects_1 = remote-stub.$(OBJEXT) +@MINGW_TRUE@am__objects_2 = pathstuff.$(OBJEXT) dirent.$(OBJEXT) \ +@MINGW_TRUE@ sub_proc.$(OBJEXT) w32err.$(OBJEXT) am_make_OBJECTS = ar.$(OBJEXT) arscan.$(OBJEXT) commands.$(OBJEXT) \ default.$(OBJEXT) dir.$(OBJEXT) expand.$(OBJEXT) file.$(OBJEXT) \ function.$(OBJEXT) getopt.$(OBJEXT) getopt1.$(OBJEXT) \ implicit.$(OBJEXT) job.$(OBJEXT) main.$(OBJEXT) misc.$(OBJEXT) \ read.$(OBJEXT) remake.$(OBJEXT) $(am__objects_1) rule.$(OBJEXT) \ signame.$(OBJEXT) variable.$(OBJEXT) version.$(OBJEXT) \ - vpath.$(OBJEXT) hash.$(OBJEXT) + vpath.$(OBJEXT) hash.$(OBJEXT) $(am__objects_2) make_OBJECTS = $(am_make_OBJECTS) -make_DEPENDENCIES = @LIBOBJS@ @ALLOCA@ +@MINGW_TRUE@make_DEPENDENCIES = @LIBOBJS@ @ALLOCA@ w32misc.o +@MINGW_FALSE@make_DEPENDENCIES = @LIBOBJS@ @ALLOCA@ make_LDFLAGS = DEFAULT_INCLUDES = -I. -I$(srcdir) -I. CPPFLAGS = @CPPFLAGS@ @@ -221,18 +232,19 @@ @AMDEP_TRUE@DEP_FILES = $(DEPDIR)/alloca.Po $(DEPDIR)/getloadavg.Po \ @AMDEP_TRUE@ ./$(DEPDIR)/ar.Po ./$(DEPDIR)/arscan.Po \ @AMDEP_TRUE@ ./$(DEPDIR)/commands.Po ./$(DEPDIR)/default.Po \ -@AMDEP_TRUE@ ./$(DEPDIR)/dir.Po ./$(DEPDIR)/expand.Po \ -@AMDEP_TRUE@ ./$(DEPDIR)/file.Po ./$(DEPDIR)/function.Po \ -@AMDEP_TRUE@ ./$(DEPDIR)/getopt.Po ./$(DEPDIR)/getopt1.Po \ -@AMDEP_TRUE@ ./$(DEPDIR)/hash.Po ./$(DEPDIR)/implicit.Po \ -@AMDEP_TRUE@ ./$(DEPDIR)/job.Po \ -@AMDEP_TRUE@ ./$(DEPDIR)/loadavg-getloadavg.Po \ -@AMDEP_TRUE@ ./$(DEPDIR)/main.Po ./$(DEPDIR)/misc.Po \ +@AMDEP_TRUE@ ./$(DEPDIR)/dir.Po ./$(DEPDIR)/dirent.Po \ +@AMDEP_TRUE@ ./$(DEPDIR)/expand.Po ./$(DEPDIR)/file.Po \ +@AMDEP_TRUE@ ./$(DEPDIR)/function.Po ./$(DEPDIR)/getopt.Po \ +@AMDEP_TRUE@ ./$(DEPDIR)/getopt1.Po ./$(DEPDIR)/hash.Po \ +@AMDEP_TRUE@ ./$(DEPDIR)/implicit.Po ./$(DEPDIR)/job.Po \ +@AMDEP_TRUE@ ./$(DEPDIR)/loadavg-loadavg.Po ./$(DEPDIR)/main.Po \ +@AMDEP_TRUE@ ./$(DEPDIR)/misc.Po ./$(DEPDIR)/pathstuff.Po \ @AMDEP_TRUE@ ./$(DEPDIR)/read.Po ./$(DEPDIR)/remake.Po \ @AMDEP_TRUE@ ./$(DEPDIR)/remote-cstms.Po \ @AMDEP_TRUE@ ./$(DEPDIR)/remote-stub.Po ./$(DEPDIR)/rule.Po \ -@AMDEP_TRUE@ ./$(DEPDIR)/signame.Po ./$(DEPDIR)/variable.Po \ -@AMDEP_TRUE@ ./$(DEPDIR)/version.Po ./$(DEPDIR)/vpath.Po +@AMDEP_TRUE@ ./$(DEPDIR)/signame.Po ./$(DEPDIR)/sub_proc.Po \ +@AMDEP_TRUE@ ./$(DEPDIR)/variable.Po ./$(DEPDIR)/version.Po \ +@AMDEP_TRUE@ ./$(DEPDIR)/vpath.Po ./$(DEPDIR)/w32err.Po COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \ $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) CCLD = $(CC) @@ -249,9 +261,10 @@ uninstall-info-recursive all-recursive install-data-recursive \ install-exec-recursive installdirs-recursive install-recursive \ uninstall-recursive check-recursive installcheck-recursive -DIST_COMMON = $(noinst_HEADERS) ABOUT-NLS AUTHORS COPYING ChangeLog \ - INSTALL Makefile.am Makefile.in NEWS acinclude.m4 aclocal.m4 \ - alloca.c config.h.in configure configure.in getloadavg.c +DIST_COMMON = README $(noinst_HEADERS) ABOUT-NLS AUTHORS COPYING \ + ChangeLog INSTALL Makefile.am Makefile.in NEWS acinclude.m4 \ + aclocal.m4 alloca.c build.sh.in config.h.in configure \ + configure.in getloadavg.c DIST_SUBDIRS = $(SUBDIRS) SOURCES = $(loadavg_SOURCES) $(make_SOURCES) $(EXTRA_make_SOURCES) @@ -322,10 +335,14 @@ clean-noinstPROGRAMS: -test -z "$(noinst_PROGRAMS)" || rm -f $(noinst_PROGRAMS) -loadavg-getloadavg.$(OBJEXT): getloadavg.c +loadavg-loadavg.$(OBJEXT): loadavg.c loadavg$(EXEEXT): $(loadavg_OBJECTS) $(loadavg_DEPENDENCIES) @rm -f loadavg$(EXEEXT) $(LINK) $(loadavg_LDFLAGS) $(loadavg_OBJECTS) $(loadavg_LDADD) $(LIBS) +pathstuff.$(OBJEXT): w32/pathstuff.c +dirent.$(OBJEXT): w32/compat/dirent.c +sub_proc.$(OBJEXT): w32/subproc/sub_proc.c +w32err.$(OBJEXT): w32/subproc/w32err.c make$(EXEEXT): $(make_OBJECTS) $(make_DEPENDENCIES) @rm -f make$(EXEEXT) $(LINK) $(make_LDFLAGS) $(make_OBJECTS) $(make_LDADD) $(LIBS) @@ -343,6 +360,7 @@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/commands.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/default.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/dir.Po@am__quote@ +@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/dirent.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/expand.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/file.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/function.Po@am__quote@ @@ -351,18 +369,21 @@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hash.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/implicit.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/job.Po@am__quote@ -@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/loadavg-getloadavg.Po@am__quote@ +@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/loadavg-loadavg.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/main.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/misc.Po@am__quote@ +@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pathstuff.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/read.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/remake.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/remote-cstms.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/remote-stub.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/rule.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/signame.Po@am__quote@ +@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/sub_proc.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/variable.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/version.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/vpath.Po@am__quote@ +@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/w32err.Po@am__quote@ distclean-depend: -rm -rf $(DEPDIR) ./$(DEPDIR) @@ -379,17 +400,65 @@ @AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ $(COMPILE) -c `cygpath -w $<` -loadavg-getloadavg.o: getloadavg.c -@AMDEP_TRUE@ source='getloadavg.c' object='loadavg-getloadavg.o' libtool=no @AMDEPBACKSLASH@ -@AMDEP_TRUE@ depfile='$(DEPDIR)/loadavg-getloadavg.Po' tmpdepfile='$(DEPDIR)/loadavg-getloadavg.TPo' @AMDEPBACKSLASH@ +loadavg-loadavg.o: loadavg.c +@AMDEP_TRUE@ source='loadavg.c' object='loadavg-loadavg.o' libtool=no @AMDEPBACKSLASH@ +@AMDEP_TRUE@ depfile='$(DEPDIR)/loadavg-loadavg.Po' tmpdepfile='$(DEPDIR)/loadavg-loadavg.TPo' @AMDEPBACKSLASH@ @AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ - $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(loadavg_CFLAGS) $(CFLAGS) -c -o loadavg-getloadavg.o `test -f 'getloadavg.c' || echo '$(srcdir)/'`getloadavg.c + $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(loadavg_CFLAGS) $(CFLAGS) -c -o loadavg-loadavg.o `test -f 'loadavg.c' || echo '$(srcdir)/'`loadavg.c -loadavg-getloadavg.obj: getloadavg.c -@AMDEP_TRUE@ source='getloadavg.c' object='loadavg-getloadavg.obj' libtool=no @AMDEPBACKSLASH@ -@AMDEP_TRUE@ depfile='$(DEPDIR)/loadavg-getloadavg.Po' tmpdepfile='$(DEPDIR)/loadavg-getloadavg.TPo' @AMDEPBACKSLASH@ +loadavg-loadavg.obj: loadavg.c +@AMDEP_TRUE@ source='loadavg.c' object='loadavg-loadavg.obj' libtool=no @AMDEPBACKSLASH@ +@AMDEP_TRUE@ depfile='$(DEPDIR)/loadavg-loadavg.Po' tmpdepfile='$(DEPDIR)/loadavg-loadavg.TPo' @AMDEPBACKSLASH@ @AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ - $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(loadavg_CFLAGS) $(CFLAGS) -c -o loadavg-getloadavg.obj `cygpath -w getloadavg.c` + $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(loadavg_CFLAGS) $(CFLAGS) -c -o loadavg-loadavg.obj `cygpath -w loadavg.c` + +pathstuff.o: w32/pathstuff.c +@AMDEP_TRUE@ source='w32/pathstuff.c' object='pathstuff.o' libtool=no @AMDEPBACKSLASH@ +@AMDEP_TRUE@ depfile='$(DEPDIR)/pathstuff.Po' tmpdepfile='$(DEPDIR)/pathstuff.TPo' @AMDEPBACKSLASH@ +@AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ + $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o pathstuff.o `test -f 'w32/pathstuff.c' || echo '$(srcdir)/'`w32/pathstuff.c + +pathstuff.obj: w32/pathstuff.c +@AMDEP_TRUE@ source='w32/pathstuff.c' object='pathstuff.obj' libtool=no @AMDEPBACKSLASH@ +@AMDEP_TRUE@ depfile='$(DEPDIR)/pathstuff.Po' tmpdepfile='$(DEPDIR)/pathstuff.TPo' @AMDEPBACKSLASH@ +@AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ + $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o pathstuff.obj `cygpath -w w32/pathstuff.c` + +dirent.o: w32/compat/dirent.c +@AMDEP_TRUE@ source='w32/compat/dirent.c' object='dirent.o' libtool=no @AMDEPBACKSLASH@ +@AMDEP_TRUE@ depfile='$(DEPDIR)/dirent.Po' tmpdepfile='$(DEPDIR)/dirent.TPo' @AMDEPBACKSLASH@ +@AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ + $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o dirent.o `test -f 'w32/compat/dirent.c' || echo '$(srcdir)/'`w32/compat/dirent.c + +dirent.obj: w32/compat/dirent.c +@AMDEP_TRUE@ source='w32/compat/dirent.c' object='dirent.obj' libtool=no @AMDEPBACKSLASH@ +@AMDEP_TRUE@ depfile='$(DEPDIR)/dirent.Po' tmpdepfile='$(DEPDIR)/dirent.TPo' @AMDEPBACKSLASH@ +@AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ + $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o dirent.obj `cygpath -w w32/compat/dirent.c` + +sub_proc.o: w32/subproc/sub_proc.c +@AMDEP_TRUE@ source='w32/subproc/sub_proc.c' object='sub_proc.o' libtool=no @AMDEPBACKSLASH@ +@AMDEP_TRUE@ depfile='$(DEPDIR)/sub_proc.Po' tmpdepfile='$(DEPDIR)/sub_proc.TPo' @AMDEPBACKSLASH@ +@AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ + $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o sub_proc.o `test -f 'w32/subproc/sub_proc.c' || echo '$(srcdir)/'`w32/subproc/sub_proc.c + +sub_proc.obj: w32/subproc/sub_proc.c +@AMDEP_TRUE@ source='w32/subproc/sub_proc.c' object='sub_proc.obj' libtool=no @AMDEPBACKSLASH@ +@AMDEP_TRUE@ depfile='$(DEPDIR)/sub_proc.Po' tmpdepfile='$(DEPDIR)/sub_proc.TPo' @AMDEPBACKSLASH@ +@AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ + $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o sub_proc.obj `cygpath -w w32/subproc/sub_proc.c` + +w32err.o: w32/subproc/w32err.c +@AMDEP_TRUE@ source='w32/subproc/w32err.c' object='w32err.o' libtool=no @AMDEPBACKSLASH@ +@AMDEP_TRUE@ depfile='$(DEPDIR)/w32err.Po' tmpdepfile='$(DEPDIR)/w32err.TPo' @AMDEPBACKSLASH@ +@AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ + $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o w32err.o `test -f 'w32/subproc/w32err.c' || echo '$(srcdir)/'`w32/subproc/w32err.c + +w32err.obj: w32/subproc/w32err.c +@AMDEP_TRUE@ source='w32/subproc/w32err.c' object='w32err.obj' libtool=no @AMDEPBACKSLASH@ +@AMDEP_TRUE@ depfile='$(DEPDIR)/w32err.Po' tmpdepfile='$(DEPDIR)/w32err.TPo' @AMDEPBACKSLASH@ +@AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ + $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o w32err.obj `cygpath -w w32/subproc/w32err.c` CCDEPMODE = @CCDEPMODE@ uninstall-info-am: @@ -737,6 +806,13 @@ uninstall-recursive +# How to build w32/subproc/misc.c +# We need this to build it to w32misc.o (there is already a misc.c which builds +# to misc.o in the toplevel directory) + +w32misc.o: + $(COMPILE) -c -o w32misc.o w32/subproc/misc.c + # Forward targets html pdf: @@ -780,11 +856,13 @@ .PHONY: check-loadavg check-regression -check-loadavg: loadavg +check-loadavg: loadavg$(EXEEXT) @echo The system uptime program believes the load average to be: -uptime @echo The GNU load average checking code thinks: -./loadavg +loadavg.c: + cp $(srcdir)/getloadavg.c loadavg.c check-regression: @if test -f "$(srcdir)/tests/run_make_tests"; then \ diff -Naurd make-3.80rc2/config.h.in make-3.80rc2-jc/config.h.in --- make-3.80rc2/config.h.in Tue Sep 10 22:16:45 2002 +++ make-3.80rc2-jc/config.h.in Fri Sep 13 16:34:40 2002 @@ -343,6 +343,9 @@ /* Version number of package */ #undef VERSION +/* Define if building on the MinGW/MSYS combination */ +#undef WINDOWS32 + /* Define if using the dmalloc debugging malloc package */ #undef WITH_DMALLOC diff -Naurd make-3.80rc2/configure make-3.80rc2-jc/configure --- make-3.80rc2/configure Tue Sep 10 22:16:48 2002 +++ make-3.80rc2-jc/configure Fri Sep 13 16:43:33 2002 @@ -6635,6 +6635,26 @@ fi +# See if we're building on the MinGW/MSYS combination +if test "$host_os" = "mingw32"; then + +cat >>confdefs.h <<\_ACEOF +#define WINDOWS32 1 +_ACEOF + +fi + + + +if test "$host_os" = "mingw32"; then + MINGW_TRUE= + MINGW_FALSE='#' +else + MINGW_TRUE='#' + MINGW_FALSE= +fi + + # Find some definition for uintmax_t echo "$as_me:$LINENO: checking for uintmax_t" >&5 @@ -11595,6 +11615,13 @@ Usually this means the macro was only invoked conditionally." >&2;} { (exit 1); exit 1; }; } fi +if test -z "${MINGW_TRUE}" && test -z "${MINGW_FALSE}"; then + { { echo "$as_me:$LINENO: error: conditional \"MINGW\" was never defined. +Usually this means the macro was only invoked conditionally." >&5 +echo "$as_me: error: conditional \"MINGW\" was never defined. +Usually this means the macro was only invoked conditionally." >&2;} + { (exit 1); exit 1; }; } +fi if test -z "${USE_CUSTOMS_TRUE}" && test -z "${USE_CUSTOMS_FALSE}"; then { { echo "$as_me:$LINENO: error: conditional \"USE_CUSTOMS\" was never defined. Usually this means the macro was only invoked conditionally." >&5 @@ -12168,6 +12195,8 @@ s,@LIBINTL@,$LIBINTL,;t t s,@LTLIBINTL@,$LTLIBINTL,;t t s,@POSUB@,$POSUB,;t t +s,@MINGW_TRUE@,$MINGW_TRUE,;t t +s,@MINGW_FALSE@,$MINGW_FALSE,;t t s,@ALLOCA@,$ALLOCA,;t t s,@LIBOBJS@,$LIBOBJS,;t t s,@NEED_SETGID@,$NEED_SETGID,;t t diff -Naurd make-3.80rc2/configure.in make-3.80rc2-jc/configure.in --- make-3.80rc2/configure.in Tue Sep 10 08:27:29 2002 +++ make-3.80rc2-jc/configure.in Fri Sep 13 16:34:22 2002 @@ -58,6 +58,13 @@ AC_TYPE_UID_T AC_TYPE_PID_T +# See if we're building on the MinGW/MSYS combination +if test "$host_os" = "mingw32"; then +AC_DEFINE(WINDOWS32, 1, [Define if building on the MinGW/MSYS combination]) +fi + +AM_CONDITIONAL(MINGW, test "$host_os" = "mingw32") + # Find some definition for uintmax_t AC_CHECK_TYPE(uintmax_t,,[ diff -Naurd make-3.80rc2/glob/Makefile.am make-3.80rc2-jc/glob/Makefile.am --- make-3.80rc2/glob/Makefile.am Mon Apr 22 05:35:20 2002 +++ make-3.80rc2-jc/glob/Makefile.am Fri Sep 13 16:34:22 2002 @@ -1,11 +1,17 @@ # -*-Makefile-*-, or close enough +if MINGW + w32_include = -I$(top_srcdir)/w32/include +endif + AUTOMAKE_OPTIONS = 1.6 foreign # Only build the library when the system doesn't already have GNU glob. if USE_LOCAL_GLOB noinst_LIBRARIES = libglob.a endif + +AM_CPPFLAGS = $(w32_include) libglob_a_SOURCES = glob.c glob.h fnmatch.c fnmatch.h diff -Naurd make-3.80rc2/glob/Makefile.in make-3.80rc2-jc/glob/Makefile.in --- make-3.80rc2/glob/Makefile.in Tue Sep 10 22:16:47 2002 +++ make-3.80rc2-jc/glob/Makefile.in Fri Sep 13 16:43:28 2002 @@ -108,10 +108,14 @@ am__quote = @am__quote@ install_sh = @install_sh@ +@MINGW_TRUE@w32_include = -I$(top_srcdir)/w32/include + AUTOMAKE_OPTIONS = 1.6 foreign # Only build the library when the system doesn't already have GNU glob. @USE_LOCAL_GLOB_TRUE@noinst_LIBRARIES = libglob.a + +AM_CPPFLAGS = $(w32_include) libglob_a_SOURCES = glob.c glob.h fnmatch.c fnmatch.h diff -Naurd make-3.80rc2/hash.h make-3.80rc2-jc/hash.h --- make-3.80rc2/hash.h Thu Aug 8 01:11:19 2002 +++ make-3.80rc2-jc/hash.h Fri Sep 13 16:34:22 2002 @@ -104,7 +104,7 @@ } while (0) #define STRING_COMPARE(X, Y, RESULT) do { \ - _RESULT_ = strcmp ((X), (Y)); \ + RESULT = strcmp ((X), (Y)); \ } while (0) #define return_STRING_COMPARE(X, Y) do { \ return strcmp ((X), (Y)); \ @@ -140,7 +140,7 @@ } while (0) #define STRING_N_COMPARE(X, Y, N, RESULT) do { \ - _RESULT_ = strncmp ((X), (Y), (N)); \ + RESULT = strncmp ((X), (Y), (N)); \ } while (0) #define return_STRING_N_COMPARE(X, Y, N) do { \ return strncmp ((X), (Y), (N)); \ @@ -173,7 +173,7 @@ } while (0) #define ISTRING_COMPARE(X, Y, RESULT) do { \ - _RESULT_ = strcmpi ((X), (Y)); \ + RESULT = strcmpi ((X), (Y)); \ } while (0) #define return_ISTRING_COMPARE(X, Y) do { \ return strcmpi ((X), (Y)); \ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mingw-msys mailing list Min...@li... https://lists.sourceforge.net/lists/listinfo/mingw-msys |
From: Soren A <sor...@fa...> - 2002-09-19 06:48:33
|
"John Cronin" <jo...@st...> wrote in news:NHE...@st...: > Now problem is, that tomorrow I'm moving and won't have internet access > (well will, but will be slow and away from my development machine). > Therefore, I won't be able to keep working away at make, and if anyone > else is interested, they have my blessing. I am on it, but slow like creeping lichen ;-). I am following all your status reports (and admiring them) and cheering for you (huh? you couldn't hear me?) but am beset by my own disruptions and dislocations (*3* different machines I am jogging frantically between at this point). Reading this your message made me practically pant to pull down the source and roll up my figurative sleeves again, but alas it could be 5 more days or so before I am settled enough and have sufficient time to get much done. > Current status report: > > {snip...} And I'm sure he doesn't need to > know about changes to configure and Makefile.in. Explain?? I don't understand. I think he does. Changes to the build- configuration setup *is* (are) changes to the package. Changes required to get a package to build cleanly and without noise and mess are just as much value-added and important in porting software as changes to C sources. Please consider me, at least, interested in not only descriptions of what you needed to change in configure.in (you wrote 'configure' but i am assuming you meant 'configure.in') and Makefile.in, but in diffs if you can manage to provide. If you didn't in fact fix configure.in but patched the (generated) file 'configure' (which i could understand) instead, then even more so, consider it a strong plea to convey to me what you did. Maybe I can support your efforts by translating your 'configure' changes to proper autoconf-based changes. > 2) Getting the changes from mingw CVS msys/packages/make version 1.2 > into the source, and having them 1. not break anything! and 2. only > activate when make is _run_ on msys, ie not from command.com. Or CMD.exe. OK, this is sounding like a fun plunge into possible deep dark magical waters. IMO you are taking a bold and daring approach by trying to create a 'make' that adapts to BOTH an MS shell and a Bourne-ish shell, instead of settling for a situation in which recompilation to a specific set configuration will be required in order to use the make if one switches shells. There could be alligators or slimy strangling snake-like things in those waters, though. Best, Soren A |
From: Soren A <sor...@fa...> - 2002-09-21 23:33:02
|
*I* myself, Soren A <soren_andersen=97j...@pu...> wrote in news:Xns928E1C9026C10SorenA9GMANE8BUF@80.91.224.249: [John Cronin]: >> Current status report: >> >> {snip...} And I'm sure he doesn't need to >> know about changes to configure and Makefile.in. > > Explain?? I don't understand. I think he does. Changes to the build- > configuration setup *is* (are) changes to the package. Changes > required to get a package to build cleanly and without noise and mess > are just as much value-added and important in porting software as > changes to C sources. > > Please consider me, at least, interested in not only descriptions of > what you needed to change in configure.in (you wrote 'configure' but i > am assuming you meant 'configure.in') and Makefile.in, but in diffs if > you can manage to provide. > > If you didn't in fact fix configure.in but patched the (generated) > file 'configure' (which i could understand) instead, then even more > so, consider it a strong plea to convey to me what you did. Maybe I > can support your efforts by translating your 'configure' changes to > proper autoconf-based changes. It seems to me that the patch posted in the article cited below has the information i want (it is 2 days older than the info you posted here, though). Sorry about the probably unnecessary noise, and when you do get back to being able to read and post about this here, I'll be looking forward to hearing from you. Message-ID: <NHE...@st...> ------------------------------------------------------------------- > Subject: Autoconfiscated make for MinGW/MSYS update > Date: Thu, 12 Sep 2002 18:26:26 +0100 > From: "John Cronin" <jo...@st...> > Newsgroups: gmane.comp.gnu.mingw.user > > I have sent my patches for make to build on MinGW/MSYS to the > maintainer (Paul Smith) for inclusion in the next version 3.81. As > 3.80 is still in rc phase, they haven't been included in CVS yet. For > those of you who can't wait, attached is a patch against 3.80rc2. Run > with patch -p0 and run autoheader, autoconf and automake after (mine > aren't the correct versions and lack certain macros). It should then > build with configure && make. Note that the tests don't yet work by > default, and an attempt to run make check will delete some of them. > Just run tests/run/make_tests instead (some fail). > > John. > > Attachment decoded: text-plain-2 > ------=_NextPart_000_0002_01C25A89.E7A9CEC0 > > Attachment decoded: make-3.80rc2-jc3.patch.gz > ------=_NextPart_000_0002_01C25A89.E7A9CEC0-- ------------------------------------------------------------------- -- --*perlspinr*-- **Helping to consume excess Internet bandwidth since 1996** |
From: Soren A <sor...@fa...> - 2002-09-25 05:01:05
|
Soren A <soren_andersen=97j...@pu...> wrote around 21 Sep 2002 news:Xns9290C6DCD5AF3sorenagmaneSH@80.91.224.249: >> If you didn't in fact fix configure.in but patched the (generated) >> file 'configure' (which i could understand) instead, then even more >> so, consider it a strong plea to convey to me what you did. Maybe I >> can support your efforts by translating your 'configure' changes to >> proper autoconf-based changes. > > It seems to me that the patch posted in the article cited below has > the information i want (it is 2 days older than the info you posted > here, though). Nope. The patch (msg ID below) posted as a targzball was superceded by the patch posted as plain text in the message body. The latter included everything in the former. It would have been helpful for yout o have stated this clearly. Being in two different formats (one targzball, one plain body text) it wasn't at all obvious. > Message-ID: > <NHENINNLIDCPAGNLPEIOGEFLCBAA.john=XI225zGN4+ej9kva/NO...@pu...ane. > org9.co.uk> The latest patch included diffs for Makefile.in and for configure. I think ideally I would want to be offered (*I* would want -- not "so-and-so over --> there would want") two separate patches -- one for the files which are basically not generated ever more than once (Makefile.am, configure.in|ac, and so on) and another for the generated files which are going to be overwritten anyway if I am going to run autotools. If we were talking about a patch for a real release of an autotooled package, this might not be true: we don't ever want to see people assuming that ordinary users are in possession of Autotools (and so will be re-generating the Autotools-generated build files). But also in the case that a patch is being submitted to a package maintainer and the package is Autotools-based, all the fixes must anyway be incorporated into the primary starting build configuration files (the input files for Autotools). As you know. When I publish my patch I'll make it a diff only against the primary Autotool files. Regards, Soren A |
From: Soren A <sor...@fa...> - 2002-09-25 06:47:34
|
Soren A <soren_andersen=97j...@pu...> wrote around 25 Sep 2002 news:Xns9294A5277FC5soren1Gmane@80.91.224.249: > When I publish my patch I'll make it a diff only against the primary > Autotool files. Attached is a patch (plain text) that is a diff ONLY against the autotools input files and program source files. It does NOT patch any of 'Makefile.in' (that's generated by running `automake' which uses as its input the "Makefile.am" found in each subdir) or 'configure' (which is generated by running `autoconf') or 'aclocal.m4' (that's generated by running `aclocal -I config/'). The patch adds one new file that wasn't part of the distro before: an m4 macro added to config/. It's a good one ;-). This patch is a cumulative diff against ftp make-3.80rc2 maintained by Paul Smith. That is, it contains whatever is left that is the work of John Cronin (whatever is still unaltered by further changes I made). Some of what John posted to mingw-msys on 14 Sep 2002 in msg id <NHE...@st...> may have already been submitted to Paul by him and placed in CVS. Please review the patch carefully in light of this, Paul. Many thanks again, John, for your work that is the basis for this patch. To you (when you get back) and others reading, I want to acknowledge that this isn't rapid progress. None of the "other issues yet to be worked out" are addressed by this patch. IMHO it's worth posting this now to wrap up my recent 'review' of your work and because getting the build solid on mingw/msys is (isn't it?) a significant prerequisite to making further progress. Regards, Soren A begin 644 make-3.80rc2_sma-vs-ps_ftp.diff M9&EF9B`M+75N:61I<F5C=&EO;F%L+6YE=RUF:6QE("UA=7(@<W)C+VUA:V4M M,RXX,')C,B]-86ME9FEL92YA;2!M;V0M<W)C+VUA:V4M,RXX,')C,E]P871C M:&5D+TUA:V5F:6QE+F%M"BTM+2!S<F,O;6%K92TS+C@P<F,R+TUA:V5F:6QE M+F%M"3(P,#(M,#<M,3$@,#(Z,S@Z-3@N,#`P,#`P,#`P("TP-#`P"BLK*R!M M;V0M<W)C+VUA:V4M,RXX,')C,E]P871C:&5D+TUA:V5F:6QE+F%M"3(P,#(M M,#DM,C4@,#$Z,S@Z-3@N,#`P,#`P,#`P("TP-#`P"D!`("TQ+#4P("LQ+#@Q M($!`"B`C(%1H:7,@:7,@82`M*BU-86ME9FEL92TJ+2P@;W(@8VQO<V4@96YO M=6=H"B`*+4%55$]-04M%7T]05$E/3E,@/2`Q+C8@9&ES="UB>FEP,@HK0554 M3TU!2T5?3U!424].4R`](&1I<W0M8GII<#(*($%#3$]#04Q?04U&3$%'4PD] M("`M22!C;VYF:6<*(`HM4U5"1$E24R`]"6=L;V(@8V]N9FEG('!O(&1O8PHK M4U5"1$E24R`](&=L;V(@8V]N9FEG('!O(&1O8PH@"BUB:6Y?4%)/1U)!35,@ M/0EM86ME"BMB:6Y?4%)/1U)!35,@/2!M86ME"B`*(&EF(%5315]#55-43TU3 M"BT@(')E;6]T92`]"7)E;6]T92UC<W1M<RYC"BL@(')E;6]T92`](')E;6]T M92UC<W1M<RYC"B!E;'-E"BT@(')E;6]T92`]"7)E;6]T92US='5B+F,**R`@ M<F5M;W1E(#T@<F5M;W1E+7-T=6(N8PH@96YD:68*(`HM;6%K95]33U520T53 M(#T)87(N8R!A<G-C86XN8R!C;VUM86YD<RYC(&1E9F%U;'0N8R!D:7(N8R!E M>'!A;F0N8R!F:6QE+F,@7`HM"0EF=6YC=&EO;BYC(&=E=&]P="YC(&=E=&]P M=#$N8R!I;7!L:6-I="YC(&IO8BYC(&UA:6XN8R!<"BT)"6UI<V,N8R!R96%D M+F,@<F5M86ME+F,@)"AR96UO=&4I(')U;&4N8R!S:6=N86UE+F,@7`HM"0EV M87)I86)L92YC('9E<G-I;VXN8R!V<&%T:"YC(&AA<V@N8PHK:68@34E.1U<* M*R`@=S,R7VEN8VQU9&4@/2`M220H=&]P7W-R8V1I<BDO=S,R+VEN8VQU9&4* M*R`@=S,R7W-O=7)C97,@/2!W,S(O<&%T:'-T=69F+F,@=S,R+V-O;7!A="]D M:7)E;G0N8R!W,S(O<W5B<')O8R]S=6)?<')O8RYC(%P**R`@('<S,B]S=6)P M<F]C+W<S,F5R<BYC"BL@('<S,E]M:7-C("`@(#T@=S,R;6ES8RYO"BME;F1I M9@HK"BMM86ME7U-/55)#15,@/2!A<BYC(&%R<V-A;BYC(&-O;6UA;F1S+F,@ M9&5F875L="YC(&1I<BYC(&5X<&%N9"YC(&9I;&4N8R!<"BL@("`@("!F=6YC M=&EO;BYC(&=E=&]P="YC(&=E=&]P=#$N8R!I;7!L:6-I="YC(&IO8BYC(&UA M:6XN8R!<"BL@("`@("!M:7-C+F,@<F5A9"YC(')E;6%K92YC("0H<F5M;W1E M*2!R=6QE+F,@<VEG;F%M92YC(%P**R`@("`@('9A<FEA8FQE+F,@=F5R<VEO M;BYC('9P871H+F,@:&%S:"YC("0H=S,R7W-O=7)C97,I"B`*($585%)!7VUA M:V5?4T]54D-%4R`](')E;6]T92US='5B+F,@<F5M;W1E+6-S=&US+F,*(`H@ M;F]I;G-T7TA%041%4E,@/2!C;VUM86YD<RYH(&1E<"YH(&9I;&5D968N:"!J M;V(N:"!M86ME+F@@<G5L92YH('9A<FEA8FQE+F@@7`HM"0ED96)U9RYH(&=E M=&]P="YH(&=E='1E>'0N:"!H87-H+F@**R`@("`@(&1E8G5G+F@@9V5T;W!T M+F@@9V5T=&5X="YH(&AA<V@N:`H@"BUM86ME7TQ$041$(#T)0$Q)0D]"2E-` M($!!3$Q/0T%`("0H1TQ/0DQ)0BD@0$=%5$Q/041!5D=?3$E"4T`@0$Q)0DE. M5$Q`"BMM86ME7TQ$041$(#T@0$Q)0D]"2E-`($!!3$Q/0T%`("0H=S,R7VUI M<V,I(%P**R`@("0H1TQ/0DQ)0BD@0$=%5$Q/041!5D=?3$E"4T`@0$Q)0DE. M5$Q`"BL**VEF($)524Q$7U=?1TY534%+10HK3$1!1$1?9'5M8B`@.CT@)"A' M3$]"3$E"*2,@4')E<&%R92!T;R!O=F5R<FED92!!=71O;6%K92!D969A=6QT M(')U;&5S+@HK3$1!1$1?<VUA<G0@.CT@)"AA9&1P<F5F:7@@+4PL)"AD:7(@ M)"A'3$]"3$E"*2DI("0H861D<')E9FEX(%P**RUL+"0H<&%T<W5B<W0@;&EB M)2YA+"4L)"AN;W1D:7(@)"A'3$]"3$E"*2DI*0HK"BMM86ME)"A%6$5%6%0I M.B!<"BL@)"AM86ME7T]"2D5#5%,I("0H;6%K95]$15!%3D1%3D-)15,I(%P* M*R`D*&EF("0H9FEN9'-T<FEN9R`D*$Q$041$7V1U;6(I+"0H;6%K95]$15!% M3D1%3D-)15,I*2PL)"A,1$%$1%]D=6UB*2D@7`HK(R!5<VEN9R!'3E4@;6%K M92!T;R!B=6EL9"!'3E4@;6%K92X@1V]I;F<@=&\@;W9E<G)I9&4@875T;VUA M:V4@<G5L97,N"BL)0')M("UF(&UA:V4D*$5814585"D**PDD*'-T<FEP("0H M3$E.2RD@)"AM86ME7TQ$1DQ!1U,I("0H;6%K95]/0DI%0U13*2!<"BL@)"AS M=6)S="`D*$Q$041$7V1U;6(I+"0H3$1!1$1?<VUA<G0I+"0H;6%K95],1$%$ M1"DI("0H3$E"4RDI"BLC($5N9"!A=71O;6%K92!O=F5R<FED9&5N+@HK96YD M:68*(`HM;6%N7TU!3E,@/0EM86ME+C$*(`HM1$5&4R`]"0DM1$Q/0T%,141) M4CU<(B0H;&]C86QE9&ER*5PB("U$3$E"1$E2/5PB)"AL:6)D:7(I7"(@+41) M3D-,541%1$E2/5PB)"AI;F-L=61E9&ER*5PB($!$14930`HK;6%N7TU!3E,@ M/2!M86ME+C$*(`HM04U?0U!01DQ!1U,@/0DD*$=,3T))3D,I"BM$1493(#T@ M+41,3T-!3$5$25(]7"(D*&QO8V%L961I<BE<(B`M1$Q)0D1)4CU<(B0H;&EB M9&ER*5PB(%P**R`@("U$24Y#3%5$141)4CU<(B0H:6YC;'5D961I<BE<(B!` M1$5&4T`*(`HK04U?0U!01DQ!1U,@/2`D*$=,3T))3D,I("0H=S,R7VEN8VQU M9&4I"BL**R,@2&]W('1O(&)U:6QD('<S,B]S=6)P<F]C+VUI<V,N8PHK(R!7 M92!N965D('1H:7,@=&\@8G5I;&0@:70@=&\@=S,R;6ES8RYO("AT:&5R92!I M<R!A;')E861Y(&$@;6ES8RYC('=H:6-H(&)U:6QD<PHK(R!T;R!M:7-C+F\@ M:6X@=&AE('1O<&QE=F5L(&1I<F5C=&]R>2D**PHK=S,R;6ES8RYO.B!W,S(O M<W5B<')O8R]M:7-C+F,**PDD*$-/35!)3$4I("UC("UO('<S,FUI<V,N;R`D M/`H@"B`C($5X=')A('-T=69F('1O(&EN8VQU9&4@:6X@=&AE(&1I<W1R:6)U M=&EO;BX*(",@3F]T92!W92!N965D(&%L;"!T:&4@9VQO8B!S='5F9B!H97)E M+"!R871H97(@=&AA;B!I;B!G;&]B+TUA:V5F:6QE+F%M+`H@(R!B96-A=7-E M(&]F=&5N('1H870@9&ER96-T;W)Y(&ES;B=T(&)U:6QT(&]N('1H92!S>7-T M96US('5S960@8GD@=&AE"B`C(&UA:6YT86EN97)S+@H@"BU%6%1205]$25-4 M(#T)4D5!1$U%(&)U:6QD+G-H+FEN("0H;6%N7TU!3E,I7`HM"0E214%$344N M8W5S=&]M<UP*+0D)4T-/4%1)3TY3(%--86ME9FEL95P*+0D)4D5!1$U%+D%M M:6=A($UA:V5F:6QE+F%M:2!C;VYF:6<N86UI(&UA:V4N;&YK(&%M:6=A+F,@ M86UI9V$N:%P*+0D)4D5!1$U%+D1/4R!-86ME9FEL92Y$3U,@8V]N9FEG=7)E M+F)A="!D;W-B=6EL9"YB870@8V]N9FEG:"YD;W-<"BT)"5)%041-12Y7,S(@ M3DUA:V5F:6QE(&-O;F9I9RYH+E<S,B!B=6EL9%]W,S(N8F%T('-U8G!R;V,N M8F%T7`HM"0ER96%D;64N=FUS(&UA:V5F:6QE+G9M<R!M86ME9FEL92YC;VT@ M8V]N9FEG+F@M=FUS(%P*+0D)=FUS9&ER+F@@=FUS9G5N8W1I;VYS+F,@=FUS M:69Y+F,**T585%)!7T1)4U0@/2!214%$344@8G5I;&0N<V@N:6X@)"AM86Y? M34%.4RE<"BL@("`@("!214%$344N8W5S=&]M<UP**R`@("`@(%-#3U!424]. M4R!336%K969I;&5<"BL@("`@("!214%$344N06UI9V$@36%K969I;&4N86UI M(&-O;F9I9RYA;6D@;6%K92YL;FL@86UI9V$N8R!A;6EG82YH7`HK("`@("`@ M4D5!1$U%+D1/4R!-86ME9FEL92Y$3U,@8V]N9FEG=7)E+F)A="!D;W-B=6EL M9"YB870@8V]N9FEG:"YD;W-<"BL@("`@("!214%$344N5S,R($Y-86ME9FEL M92!C;VYF:6<N:"Y7,S(@8G5I;&1?=S,R+F)A="!S=6)P<F]C+F)A=%P**R`@ M("`@(')E861M92YV;7,@;6%K969I;&4N=FUS(&UA:V5F:6QE+F-O;2!C;VYF M:6<N:"UV;7,@7`HK("`@("`@=FUS9&ER+F@@=FUS9G5N8W1I;VYS+F,@=FUS M:69Y+F,*(`H@34%+15](3U-4(#T)0$U!2T5?2$]35$`*(`I`0"`M,3$S+#<@ M*S$T-"PW($!`"B`*("Y02$].63H@8VAE8VLM;&]A9&%V9R!C:&5C:RUR96=R M97-S:6]N"B`*+6-H96-K+6QO861A=F<Z(&QO861A=F<**V-H96-K+6QO861A M=F<Z(&QO861A=F<D*$5814585"D*(`E`96-H;R!4:&4@<WES=&5M('5P=&EM M92!P<F]G<F%M(&)E;&EE=F5S('1H92!L;V%D(&%V97)A9V4@=&\@8F4Z"B`) M+75P=&EM90H@"4!E8VAO(%1H92!'3E4@;&]A9"!A=F5R86=E(&-H96-K:6YG M(&-O9&4@=&AI;FMS.@I`0"`M,3(Q+#$P("LQ-3(L,3,@0$`*(`H@(R!4:&4@ M;&]A9&%V9R!F=6YC=&EO;B!I<R!I;G9O:V5D(&1U<FEN9R`B;6%K92!C:&5C M:R(@=&\@=&5S="!G971L;V%D879G+@H@;F]I;G-T7U!23T=204U3(#T@;&]A M9&%V9PHM;&]A9&%V9U]33U520T53(#T@9V5T;&]A9&%V9RYC"BML;V%D879G M7U-/55)#15,@/2!L;V%D879G+F,**VQO861A=F<N8SH@)"AS<F-D:7(I+V=E M=&QO861A=F<N8PHK"6-P("0H<W)C9&ER*2]G971L;V%D879G+F,@)$`*(&QO M861A=F=?0T9,04=3(#T@+41415-4"B!L;V%D879G7TQ$041$(#T@0$=%5$Q/ M041!5D=?3$E"4T`*(`HK"B`C(#X@8VAE8VLM<F5G<F5S<VEO;@H@(PH@(R!, M;V]K(&9O<B!T:&4@;6%K92!T97-T('-U:71E+"!A;F0@<G5N(&ET(&EF(&9O M=6YD(&%N9"!W92!C86X@9FEN9"!P97)L+@ID:69F("TM=6YI9&ER96-T:6]N M86PM;F5W+69I;&4@+6%U<B!S<F,O;6%K92TS+C@P<F,R+V-O;F9I9R]-86ME M9FEL92YA;2!M;V0M<W)C+VUA:V4M,RXX,')C,E]P871C:&5D+V-O;F9I9R]- M86ME9FEL92YA;0HM+2T@<W)C+VUA:V4M,RXX,')C,B]C;VYF:6<O36%K969I M;&4N86T),C`P,BTP.2TP,R`Q-SHT,SHP-"XP,#`P,#`P,#`@+3`T,#`**RLK M(&UO9"US<F,O;6%K92TS+C@P<F,R7W!A=&-H960O8V]N9FEG+TUA:V5F:6QE M+F%M"3(P,#(M,#DM,C0@,3@Z,3,Z-3(N,#`P,#`P,#`P("TP-#`P"D!`("TQ M+#0@*S$L-"!`0`HM15A44D%?1$E35"`]"6-O9&5S970N;30@9V5T=&5X="YM M-"!G;&EB8S(Q+FTT(&EC;VYV+FTT(&ES8RUP;W-I>"YM-"!<"BT)"6EN=&1I M=C`N;30@:6YT='EP97,M<')I+FTT(&EN='1Y<&5S+FTT(&EN='1Y<&5S7V@N M;30@7`HM"0EI<V,M<&]S:7@N;30@;&-M97-S86=E+FTT(&QI8BUL9"YM-"!L M:6(M;&EN:RYM-"!L:6(M<')E9FEX+FTT(%P*+0D)<')O9W1E<W0N;30@<W1D M:6YT7V@N;30@=6EN=&UA>%]T+FTT('5L;VYG;&]N9RYM-`HK15A44D%?1$E3 M5"`](&-H96-K+6=N=2UM86ME+FTT(&-O9&5S970N;30@9V5T=&5X="YM-"!G M;&EB8S(Q+FTT(&EC;VYV+FTT(%P**R`@(&ES8RUP;W-I>"YM-"!I;G1D:78P M+FTT(&EN='1Y<&5S+7!R:2YM-"!I;G1T>7!E<RYM-"!I;G1T>7!E<U]H+FTT M(%P**R`@(&ES8RUP;W-I>"YM-"!L8VUE<W-A9V4N;30@;&EB+6QD+FTT(&QI M8BUL:6YK+FTT(&QI8BUP<F5F:7@N;30@7`HK("`@<')O9W1E<W0N;30@<W1D M:6YT7V@N;30@=6EN=&UA>%]T+FTT('5L;VYG;&]N9RYM-`ID:69F("TM=6YI M9&ER96-T:6]N86PM;F5W+69I;&4@+6%U<B!S<F,O;6%K92TS+C@P<F,R+V-O M;F9I9R]C:&5C:RUG;G4M;6%K92YM-"!M;V0M<W)C+VUA:V4M,RXX,')C,E]P M871C:&5D+V-O;F9I9R]C:&5C:RUG;G4M;6%K92YM-`HM+2T@<W)C+VUA:V4M M,RXX,')C,B]C;VYF:6<O8VAE8VLM9VYU+6UA:V4N;30),3DV.2TQ,BTS,2`Q M.3HP,#HP,"XP,#`P,#`P,#`@+3`U,#`**RLK(&UO9"US<F,O;6%K92TS+C@P M<F,R7W!A=&-H960O8V]N9FEG+V-H96-K+6=N=2UM86ME+FTT"3(P,#(M,#DM M,C0@,34Z,S,Z,#`N,#`P,#`P,#`P("TP-#`P"D!`("TP+#`@*S$L,C8@0$`* M*V1N;"`C(R,@:'1T<#HO+V%C+6%R8VAI=F4N<V]U<F-E9F]R9V4N;F5T+TEN M<W1A;&QE9%]086-K86=E<R]C:&5C:U]G;G5?;6%K92YH=&UL(",C(PHK"BM! M0U]$14953BA;0TA%0TM?1TY57TU!2T5=+%L**R`@("`@04-?0T%#2$5?0TA% M0TLH(&9O<B!'3E4@;6%K92Q?8W9?9VYU7VUA:V5?8V]M;6%N9"P**PD)"2`@ M7V-V7V=N=5]M86ME7V-O;6UA;F0])R<**V1N;"!396%R8V@@86QL('1H92!C M;VUM;VX@;F%M97,@9F]R($=.52!M86ME"BL)"0D@(&9O<B!A(&EN("(D34%+ M12(@;6%K92!G;6%K92!G;G5M86ME(#L@9&\**PD)"0D)("!I9B!T97-T("UZ M("(D82(@.R!T:&5N(&-O;G1I;G5E(#L@9FD@.PHK"0D)"0D@(&EF("`H('-H M("UC("(D82`M+79E<G-I;VXB(#(^("]D978O;G5L;"!\(&=R97`@1TY5("`R M/B8Q(#X@+V1E=B]N=6QL("D**R`@("`@("`@("`@("`@("`@("`@("`@("!T M:&5N"BL)"0D)"0D)("!?8W9?9VYU7VUA:V5?8V]M;6%N9#TD80HK"0D)"0D) M"2`@8G)E86L**PD)"0D)("!F:0HK"0D)("!D;VYE"BL)("`I"BMD;FP@268@ M=&AE<F4@=V%S(&$@1TY5('9E<G-I;VXL('1H96X@<V5T($!I9D=.56UA:V5` M('1O('1H92!E;7!T>2!S=')I;F<L("<C)R!O=&AE<G=I<V4**R`@("`@("`@ M:68@=&5S="`@(G@D7V-V7V=N=5]M86ME7V-O;6UA;F0B("$](")X(@HK("`@ M("`@("`@('1H96X**R`@("`@("`@("`@("`@("!I9D=.56UA:V4])R<**R`@ M("`@("`@("!E;'-E"BL@("`@("`@("`@("`@("`@:69'3E5M86ME/2<C)PHK M("`@("`@("`@("`@("`@($%#7TU31U]215-53%0H6TYO="!F;W5N9%TI"BL@ M("`@("`@(&9I"BL@("`@("`@($%#7U-50E-4*&EF1TY5;6%K92D**UT@*0HK M"F1I9F8@+2UU;FED:7)E8W1I;VYA;"UN97<M9FEL92`M875R('-R8R]M86ME M+3,N.#!R8S(O8V]N9FEG+F@N:6X@;6]D+7-R8R]M86ME+3,N.#!R8S)?<&%T M8VAE9"]C;VYF:6<N:"YI;@HM+2T@<W)C+VUA:V4M,RXX,')C,B]C;VYF:6<N M:"YI;@DR,#`R+3`Y+3$P(#$W.C$V.C0V+C`P,#`P,#`P,"`M,#0P,`HK*RL@ M;6]D+7-R8R]M86ME+3,N.#!R8S)?<&%T8VAE9"]C;VYF:6<N:"YI;@DR,#`R M+3`Y+3(S(#`U.C`Y.C$V+C`P,#`P,#`P,"`M,#0P,`I`0"`M,S0S+#8@*S,T M,RPY($!`"B`O*B!697)S:6]N(&YU;6)E<B!O9B!P86-K86=E("HO"B`C=6YD M968@5D524TE/3@H@"BLO*B!$969I;F4@:68@8G5I;&1I;F<@;VX@=&AE($UI M;D=7+TU365,@8V]M8FEN871I;VX@*B\**R-U;F1E9B!724Y$3U=3,S(**PH@ M+RH@1&5F:6YE(&EF('5S:6YG('1H92!D;6%L;&]C(&1E8G5G9VEN9R!M86QL M;V,@<&%C:V%G92`J+PH@(W5N9&5F(%=)5$A?1$U!3$Q/0PH@"F1I9F8@+2UU M;FED:7)E8W1I;VYA;"UN97<M9FEL92`M875R('-R8R]M86ME+3,N.#!R8S(O M8V]N9FEG=7)E+FEN(&UO9"US<F,O;6%K92TS+C@P<F,R7W!A=&-H960O8V]N M9FEG=7)E+FEN"BTM+2!S<F,O;6%K92TS+C@P<F,R+V-O;F9I9W5R92YI;@DR M,#`R+3`Y+3$P(#`S.C(W.C,P+C`P,#`P,#`P,"`M,#0P,`HK*RL@;6]D+7-R M8R]M86ME+3,N.#!R8S)?<&%T8VAE9"]C;VYF:6=U<F4N:6X),C`P,BTP.2TR M-"`Q.#HU,3HR-"XP,#`P,#`P,#`@+3`T,#`*0$`@+3$L,3D@*S$L,C<@0$`* M(",@4')O8V5S<R!T:&ES(&9I;&4@=VET:"!A=71O8V]N9B!T;R!P<F]D=6-E M(&$@8V]N9FEG=7)E('-C<FEP="X*+0H@04-?24Y)5"A'3E4@;6%K92PS+C@P M<F,R+&)U9RUM86ME0&=N=2YO<F<I"BT*($%#7U!215)%42@R+C4S*0HM"B!! M0U]2159)4TE/3BA;6R1)9#H@8V]N9FEG=7)E+FEN+'8@,2XQ,3,@,C`P,B\P M.2\Q,"`P-SHR-SHR.2!P<VUI=&@@17AP("1=72D*(`H@(R!!=71O8V]N9B!S M971U<`H@04-?0T].1DE'7T%56%]$25(H8V]N9FEG*0H@04-?0T].1DE'7U-2 M0T1)4BAV<&%T:"YC*0H@04U?0T].1DE'7TA%041%4BAC;VYF:6<N:"D**T%# M7T-!3D].24-!3%](3U-4"B`*(",@075T;VUA:V4@<V5T=7`*+4%-7TE.251? M05543TU!2T4**VEF('1E<W0@(B1H;W-T7V]S(B`](")M:6YG=S,R(@HK("!T M:&5N($%-7TE.251?05543TU!2T4H,2XV(&YO+61E<&5N9&5N8VEE<RD**R`@ M96QS92!!35])3DE47T%55$]-04M%"BMF:0H@04-?4%)/1U]-04M%7U-%5`HK M0TA%0TM?1TY57TU!2T4**T%-7TU!24Y404E.15)?34]$10HK(R!786YT(&-E M<G1A:6X@9F5A='5R97,@;V8@1TY5(&UA:V4L(&)U="!C86X@;&EV92!W:71H M;W5T('1H96T@;V8@8V]U<G-E+@HK04U?0T].1$E424].04PH0E5)3$1?5U]' M3E5-04M%+"!;('1E<W0@(")X)%]C=E]G;G5?;6%K95]C;VUM86YD(B`A/2`B M>")=*0HK:68@=&5S="`@(G@D7V-V7V=N=5]M86ME7V-O;6UA;F0B("$](")X M(@HK("!T:&5N($=-04M%/2(D>U]C=E]G;G5?;6%K95]C;VUM86YD?2(**V9I M"B`*(",@0VAE8VMS(&9O<B!P<F]G<F%M<RX*($%#7U!23T=?0T,*0$`@+3(U M+#<@*S,S+#8@0$`*($%#7T-(14-+7U!23T<H4$523"P@<&5R;"P@<&5R;"P@ M<&5R;"D*(`H@(R!3<&5C:6%L:7IE9"!S>7-T96T@;6%C<F]S"BU!0U]#04Y/ M3DE#04Q?2$]35`H@04-?04E8"B!!0U])4T-?4$]325@*($%#7TU)3DE8"D!` M("TU."PQ-2`K-C4L,3D@0$`*($%#7U194$5?54E$7U0*($%#7U194$5?4$E$ M7U0*(`HM(R!&:6YD('-O;64@9&5F:6YI=&EO;B!F;W(@=6EN=&UA>%]T"BLC M(%-E92!I9B!W92=R92!B=6EL9&EN9R!O;B!T:&4@36EN1U<O35-94R!C;VUB M:6YA=&EO;@HK:68@=&5S="`B)&AO<W1?;W,B(#T@(FUI;F=W,S(B.R!T:&5N M"BM!0U]$149)3D4H5TE.1$]74S,R+"`Q+"!;1&5F:6YE(&EF(&)U:6QD:6YG M(&]N('1H92!-:6Y'5R]-4UE3(&-O;6)I;F%T:6]N72D**V9I"BM!35]#3TY$ M251)3TY!3"A-24Y'5RP@=&5S="`B)&AO<W1?;W,B(#T@(FUI;F=W,S(B*0H@ M"BLC($9I;F0@<V]M92!D969I;FET:6]N(&9O<B!U:6YT;6%X7W0*($%#7T-( M14-+7U194$4H=6EN=&UA>%]T+"Q;"B`@('5I;G1M87A?=#TB=6YS:6=N960@ M;&]N9R(*("`@04-?0TA%0TM?5%E012AU;G-I9VYE9"!L;VYG(&QO;F<L6W5I M;G1M87A?=#TB=6YS:6=N960@;&]N9R!L;VYG(ETI"B`@($%#7T1%1DE.15]5 M3E%53U1%1"AU:6YT;6%X7W0L)'5I;G1M87A?="Q;1&5F:6YE('5I;G1M87A? M="!I9B!N;W0@9&5F:6YE9"!I;B`\<W1D:6YT+F@^(&]R(#QI;G1T>7!E<RYH M/BY=*5TI"B`*(",@1FEN9"!O=70@=VAE=&AE<B!O=7(@<W1R=6-T('-T870@ M<F5T=7)N<R!N86YO<V5C;VYD(')E<V]L=71I;VX@=&EM97-T86UP<RX*+0H@ M04-?4U1254-47U-47TU424U?3E-%0PH@04-?35-'7T-(14-+24Y'*%MW:&5T M:&5R('1O('5S92!H:6=H(')E<V]L=71I;VX@9FEL92!T:6UE<W1A;7!S72D* M($%#7T-!0TA%7U9!3"AM86ME7V-V7V9I;&5?=&EM97-T86UP7VAI7W)E<RP@ M6PID:69F("TM=6YI9&ER96-T:6]N86PM;F5W+69I;&4@+6%U<B!S<F,O;6%K M92TS+C@P<F,R+V=L;V(O36%K969I;&4N86T@;6]D+7-R8R]M86ME+3,N.#!R M8S)?<&%T8VAE9"]G;&]B+TUA:V5F:6QE+F%M"BTM+2!S<F,O;6%K92TS+C@P M<F,R+V=L;V(O36%K969I;&4N86T),C`P,BTP-"TR,B`P,#HS-3HR,"XP,#`P M,#`P,#`@+3`T,#`**RLK(&UO9"US<F,O;6%K92TS+C@P<F,R7W!A=&-H960O M9VQO8B]-86ME9FEL92YA;0DR,#`R+3`Y+3(R(#$Y.C,Q.C0P+C`P,#`P,#`P M,"`M,#0P,`I`0"`M,2PU("LQ+#D@0$`*(",@+2HM36%K969I;&4M*BTL(&]R M(&-L;W-E(&5N;W5G:`H@"BMI9B!-24Y'5PHK("!W,S)?:6YC;'5D92`]"2U) M)"AT;W!?<W)C9&ER*2]W,S(O:6YC;'5D90HK96YD:68**PH@05543TU!2T5? M3U!424].4R`]"3$N-B!F;W)E:6=N"B`*(",@3VYL>2!B=6EL9"!T:&4@;&EB M<F%R>2!W:&5N('1H92!S>7-T96T@9&]E<VXG="!A;')E861Y(&AA=F4@1TY5 M(&=L;V(N"D!`("TW+#8@*S$Q+#@@0$`*("`@;F]I;G-T7TQ)0E)!4DE%4R`] M"6QI8F=L;V(N80H@96YD:68*(`HK04U?0U!01DQ!1U,@/2`))"AW,S)?:6YC M;'5D92D**PH@;&EB9VQO8E]A7U-/55)#15,@/0EG;&]B+F,@9VQO8BYH(&9N M;6%T8V@N8R!F;FUA=&-H+F@*(`H@"F1I9F8@+2UU;FED:7)E8W1I;VYA;"UN M97<M9FEL92`M875R('-R8R]M86ME+3,N.#!R8S(O:&%S:"YH(&UO9"US<F,O M;6%K92TS+C@P<F,R7W!A=&-H960O:&%S:"YH"BTM+2!S<F,O;6%K92TS+C@P M<F,R+VAA<V@N:`DR,#`R+3`X+3`W(#(P.C$Q.C(P+C`P,#`P,#`P,"`M,#0P M,`HK*RL@;6]D+7-R8R]M86ME+3,N.#!R8S)?<&%T8VAE9"]H87-H+F@),C`P M,BTP.2TR,B`Q.3HS,3HT,BXP,#`P,#`P,#`@+3`T,#`*0$`@+3$P-"PW("LQ M,#0L-R!`0`H@?2!W:&EL92`H,"D*(`H@(V1E9FEN92!35%))3D=?0T]-4$%2 M12A8+"!9+"!215-53%0I(&1O('L@7`HM("!?4D5354Q47R`]('-T<F-M<"`H M*%@I+"`H62DI.R!<"BL@(%)%4U5,5"`]('-T<F-M<"`H*%@I+"`H62DI.R!< M"B!]('=H:6QE("@P*0H@(V1E9FEN92!R971U<FY?4U1224Y'7T-/35!!4D4H M6"P@62D@9&\@>R!<"B`@(')E='5R;B!S=')C;7`@*"A8*2P@*%DI*3L@7`I` M0"`M,30P+#<@*S$T,"PW($!`"B!]('=H:6QE("@P*0H@"B`C9&5F:6YE(%-4 M4DE.1U].7T-/35!!4D4H6"P@62P@3BP@4D5354Q4*2!D;R![(%P*+2`@7U)% M4U5,5%\@/2!S=')N8VUP("@H6"DL("A9*2P@*$XI*3L@7`HK("!215-53%0@ M/2!S=')N8VUP("@H6"DL("A9*2P@*$XI*3L@7`H@?2!W:&EL92`H,"D*("-D M969I;F4@<F5T=7)N7U-44DE.1U].7T-/35!!4D4H6"P@62P@3BD@9&\@>R!< M"B`@(')E='5R;B!S=')N8VUP("@H6"DL("A9*2P@*$XI*3L@7`I`0"`M,3<S M+#<@*S$W,RPW($!`"B!]('=H:6QE("@P*0H@"B`C9&5F:6YE($E35%))3D=? M0T]-4$%212A8+"!9+"!215-53%0I(&1O('L@7`HM("!?4D5354Q47R`]('-T M<F-M<&D@*"A8*2P@*%DI*3L@7`HK("!215-53%0@/2!S=')C;7!I("@H6"DL M("A9*2D[(%P*('T@=VAI;&4@*#`I"B`C9&5F:6YE(')E='5R;E])4U1224Y' M7T-/35!!4D4H6"P@62D@9&\@>R!<"B`@(')E='5R;B!S=')C;7!I("@H6"DL )("A9*2D[(%P* ` end |
From: Soren A <sor...@fa...> - 2002-09-25 06:58:05
|
Soren A <soren_andersen=97j...@pu...> wrote around 25 Sep 2002 news:Xns92941C6313697soren1Gmane@80.91.224.249: > > Attached is a patch (plain text) Sheesh, never-ending things to learn. My newsreader used base-64 encoding, it appears, on the file attachment. I wasn't expecting that. Paul, if this is a problem I'll repost. Soren A |
From: Paul D. S. <ps...@gn...> - 2002-09-25 17:13:17
|
Having it in base-64 isn't a problem per se, but it would be nice if it were a MIME attachment; then my mailer could deal with it instead of my having to save it off and do it by hand :). But, when I tried to base64 decode it I got an error: base64 encoding incomplete: at least 2 bits missing ...? -- ------------------------------------------------------------------------------- Paul D. Smith <ps...@gn...> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist |
From: Soren A <sor...@fa...> - 2002-09-23 09:28:44
|
"John Cronin" <jo...@st...> wrote in news:NHE...@st...: > Current status report: > > I have a patch for make-3.80rc2 to allow it to configure && make OOB > on msys and mingw (without breaking building on anything else). What > you get is a windows32 build (ie it expects to be run from command.com > and outputs windows style paths etc. - pretty much like mingw-make). OK. I have applied this patch to make-3.80rc2, and built 'make'. First of all, one hunk in the patch failed: Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naurd make-3.80rc2/Makefile.in make-3.80rc2-jc/Makefile.in |--- make-3.80rc2/Makefile.in Tue Sep 10 22:16:47 2002 |+++ make-3.80rc2-jc/Makefile.in Fri Sep 13 16:43:28 2002 -------------------------- Patching file `Makefile.in' using Plan A... Hunk #1 succeeded at 119. Hunk #2 succeeded at 137. Hunk #3 succeeded at 184. Hunk #4 succeeded at 204. Hunk #5 succeeded at 232. Hunk #6 succeeded at 261. Hunk #7 FAILED at 335. Hunk #8 succeeded at 360. Hunk #9 succeeded at 369. Hunk #10 succeeded at 400. Hunk #11 succeeded at 806. Hunk #12 succeeded at 856. 1 out of 12 hunks FAILED -- saving rejects to Makefile.in.rej I patched this manually. Then, there are some errors in the build configuration for me that I'll try to describe here. Before I do, I should note that I ran `autoconf' and `automake' (bleah) on the source dir, but not `autoheader'; my autoheader is broken (that is to say the Autotools I have available are not totally working -- surprise! -- they are running on Cygwin and Autotools on Cygwin are a miserable experience of endless partial unworkability). I do not know if that pertains to the errors I am getting. [All the errors are, I *think*, locateable in the top-level Makefile.] (1) The error: make[1]: Entering directory `/k/WinNT_sees_now/tmpbuilddir/gmakes/make-3.80rc2_build' [...] h:\src\make-3.80rc2_patched\dir.c:1072: glob.h: No such file or directory Analysis: In the top-level of the build dir, <dir.c> includes header <glob/glob.h>. That's not going to work using the Makefile I was able to generate because glob/ isn't in the include dirs (those passed by '-I'). In your Makefile.am I see that you have the line that's like this: AM_CPPFLAGS = $(GLOBINC) $(w32_include) And that line was probably supposed to take care of the problem. But my Makefile has: GLOBINC = GLOBLIB = So nothing is in those macros. See (3) below. (2) The error: make[1]: Entering directory `/k/WinNT_sees_now/tmpbuilddir/gmakes/make-3.80rc2_build' gcc -DLOCALEDIR=\"/usr/local/share/locale\" -DLIBDIR=\"/usr/local/lib\" -DINCLUDEDIR=\"/usr/local/include\" -DHAVE_CONFIG_H -I. -I/h/src/make-3.80rc2_patched -I. -I/h/src/make-3.80rc2_patched/glob -I/h/src/make-3.80rc2_patched/w32/include -O2 -Wundef -Wimplicit-function-declaration -mcpu=i586 -c -o w32misc.o w32/subproc/misc.c gcc.exe: w32/subproc/misc.c: No such file or directory gcc.exe: No input files make[1]: *** [w32misc.o] Error 1 Analysis: This rule wasn't written in the best way. To keep this build portable and GNU-proper all rules must allow building outside the source dir (which I generally do but I think John, you may not have been). The way I know how to fix this is to rewrite the rule like this: w32misc.o: w32/subproc/misc.c $(COMPILE) -c -o w32misc.o $< Which then finds the .c file because the top of the makefile has the src dir in VPATH. (3) The error: make[1]: Entering directory `/k/WinNT_sees_now/tmpbuilddir/gmakes/make-3.80rc2_build' gcc -O2 -Wundef -Wimplicit-function-declaration -mcpu=i586 -o make.exe ar.o arscan.o commands.o default.o dir.o expand.o file.o function.o getopt.o getopt1.o implicit.o job.o main.o misc.o read.o remake.o remote-stub.o rule.o signame.o variable.o version.o vpath.o hash.o pathstuff.o dirent.o sub_proc.o w32err.o getloadavg.o w32misc.o ar.o(.text+0x486)://h/src/make-3.80rc2_patched/ar.c: undefined reference to `fnmatch' read.o(.text+0x45a6)://h/src/make-3.80rc2_patched/read.c: undefined reference to `glob' read.o(.text+0x47c9)://h/src/make-3.80rc2_patched/read.c: undefined reference to `globfree' make[1]: *** [make.exe] Error 1 Analysis: This is a basic link-time failure obviously, and is connected to (1) above. Because the macro GLOBLIB is empty, no go. An entry like the following needs to be in GLOBLIB: -L$(top_builddir)/glob -lglob Regards, Soren A ------ original message ------- > What needs to be done is: > > 1) Submitting all changes in this patch (minus two - the hash.h one > and the loadavg one - they have already been fixed in CVS) to the > current make maintainer (Paul Smith). In fact he already has all > apart from the glob subdirectory Makefile.am one. And I'm sure he > doesn't need to know about changes to configure and Makefile.in. > > 2) Getting the changes from mingw CVS msys/packages/make version 1.2 > into the source, and having them 1. not break anything! and 2. only > activate when make is _run_ on msys, ie not from command.com. > -- --*perlspinr*-- **Helping to consume excess Internet bandwidth since 1996** |
From: Soren A <sor...@fa...> - 2002-09-24 23:19:05
|
I continue to update my own postings. Just wondering, is *anybody* at all reading this? Chirp if you exist. *I*, Soren A <soren_andersen=97j...@pu...> wrote around 23 Sep 2002 news:Xns929237B60DB47sorenagmaneSH@80.91.224.249: > > (1) The error: > make[1]: Entering directory > `/k/WinNT_sees_now/tmpbuilddir/gmakes/make-3.80rc2_build' [...] > h:\src\make-3.80rc2_patched\dir.c:1072: glob.h: No such file or > directory > > Analysis: In the top-level of the build dir, <dir.c> includes header > <glob/glob.h>. That's not going to work using the Makefile I was able > to generate because glob/ isn't in the include dirs (those passed by > '-I'). > > In your Makefile.am I see that you have the line that's like this: > > AM_CPPFLAGS = $(GLOBINC) $(w32_include) > > And that line was probably supposed to take care of the problem. But > my Makefile has: > > GLOBINC = > GLOBLIB = > > So nothing is in those macros. See (3) below. ADDITION: OK, now I am on a *different* machine running the *same* Cygwin-everything and so forth. But I upgraded _MinGW_ to the newest gcc-3.2 and everything else I could lay my hands on last night: binutils, win32-api, MinGW-runtime, etc etc. And now, for no apparent reason, the trouble documented in (1) and (3) has gone away; 'configure' successfully substitutes into these two macros and things are better -- but not really right, yet. Because of the way it's done by Automake, the entire <libglob.a> archive is added to 'make.exe', thus bloating it. Because it is passed as a complete archive name instead using -Lbar/ -lfoo syntax. I have worked that out (so that it is conditionally fixed for us and some other users without changing it for everyone in the Universe) by modifying the GNU autotools build configuration files (configure.in, Makefile.am). I will post an announcement of a URL where my changes will be published, later. > (2) The error: > make[1]: Entering directory > `/k/WinNT_sees_now/tmpbuilddir/gmakes/make-3.80rc2_build' gcc > -DLOCALEDIR=\"/usr/local/share/locale\" -DLIBDIR=\"/usr/local/lib\" > -DINCLUDEDIR=\"/usr/local/include\" -DHAVE_CONFIG_H -I. > -I/h/src/make-3.80rc2_patched -I. -I/h/src/make-3.80rc2_patched/glob > -I/h/src/make-3.80rc2_patched/w32/include -O2 -Wundef > -Wimplicit-function-declaration -mcpu=i586 -c -o w32misc.o > w32/subproc/misc.c gcc.exe: w32/subproc/misc.c: No such file or > directory gcc.exe: No input files > make[1]: *** [w32misc.o] Error 1 > > Analysis: This rule wasn't written in the best way. To keep this build > portable and GNU-proper all rules must allow building outside the > source dir (which I generally do but I think John, you may not have > been). The way I know how to fix this is to rewrite the rule like > this: > > w32misc.o: w32/subproc/misc.c > $(COMPILE) -c -o w32misc.o $< CORRECTION: GNU does not recommend this -- this is wrong (my fix was wrong). Some 'make' programs won't do this right. It should be, instead: loadavg.c: $(srcdir)/getloadavg.c cp $(srcdir)/getloadavg.c $@ > Which then finds the .c file because the top of the makefile has the > src dir in VPATH. > > (3) The error: > make[1]: Entering directory > `/k/WinNT_sees_now/tmpbuilddir/gmakes/make-3.80rc2_build' gcc -O2 > -Wundef -Wimplicit-function-declaration -mcpu=i586 -o make.exe > ar.o arscan.o commands.o default.o dir.o expand.o file.o > function.o getopt.o getopt1.o implicit.o job.o main.o misc.o read.o > remake.o remote-stub.o rule.o signame.o variable.o version.o > vpath.o hash.o pathstuff.o dirent.o sub_proc.o w32err.o > getloadavg.o w32misc.o > ar.o(.text+0x486)://h/src/make-3.80rc2_patched/ar.c: undefined > reference to `fnmatch' > read.o(.text+0x45a6)://h/src/make-3.80rc2_patched/read.c: undefined > reference to `glob' > read.o(.text+0x47c9)://h/src/make-3.80rc2_patched/read.c: undefined > reference to `globfree' make[1]: *** [make.exe] Error 1 > > Analysis: This is a basic link-time failure obviously, and is > connected to (1) above. Because the macro GLOBLIB is empty, no go. An > entry like the following needs to be in GLOBLIB: > > -L$(top_builddir)/glob -lglob As per above, this was a major issue (because I decided to make it one ;-). Regards to all, Soren A |
From: Earnie B. <ear...@ya...> - 2002-09-25 01:06:33
|
Soren A wrote: > > I continue to update my own postings. Just wondering, is *anybody* at > all reading this? Chirp if you exist. > *I*, Soren A <soren_andersen=97j...@pu...> wrote > around 23 Sep 2002 news:Xns929237B60DB47sorenagmaneSH@80.91.224.249: > Yes, but you'll probably get a better audience at mak...@gn.... > > > > (1) The error: > > make[1]: Entering directory > > `/k/WinNT_sees_now/tmpbuilddir/gmakes/make-3.80rc2_build' [...] > > h:\src\make-3.80rc2_patched\dir.c:1072: glob.h: No such file or > > directory > > > > Analysis: In the top-level of the build dir, <dir.c> includes header > > <glob/glob.h>. That's not going to work using the Makefile I was able > > to generate because glob/ isn't in the include dirs (those passed by > > '-I'). > > > > In your Makefile.am I see that you have the line that's like this: > > > > AM_CPPFLAGS = $(GLOBINC) $(w32_include) > > > > And that line was probably supposed to take care of the problem. But > > my Makefile has: > > > > GLOBINC = > > GLOBLIB = > > > > So nothing is in those macros. See (3) below. > > ADDITION: OK, now I am on a *different* machine running the *same* > Cygwin-everything and so forth. But I upgraded _MinGW_ to the newest > gcc-3.2 and everything else I could lay my hands on last night: > binutils, win32-api, MinGW-runtime, etc etc. And now, for no apparent > reason, the trouble documented in (1) and (3) has gone away; 'configure' > successfully substitutes into these two macros and things are better -- > but not really right, yet. Because of the way it's done by Automake, the > entire <libglob.a> archive is added to 'make.exe', thus bloating it. > > Because it is passed as a complete archive name instead using -Lbar/ > -lfoo syntax. I have worked that out (so that it is conditionally fixed > for us and some other users without changing it for everyone in the > Universe) by modifying the GNU autotools build configuration files > (configure.in, Makefile.am). I will post an announcement of a URL where > my changes will be published, later. > I don't really care about what the "autotools" do with your Makefile for this post. It's not relevant. If autotools get it wrong go complain to their lists. > > (2) The error: > > make[1]: Entering directory > > `/k/WinNT_sees_now/tmpbuilddir/gmakes/make-3.80rc2_build' gcc > > -DLOCALEDIR=\"/usr/local/share/locale\" -DLIBDIR=\"/usr/local/lib\" > > -DINCLUDEDIR=\"/usr/local/include\" -DHAVE_CONFIG_H -I. > > -I/h/src/make-3.80rc2_patched -I. -I/h/src/make-3.80rc2_patched/glob > > -I/h/src/make-3.80rc2_patched/w32/include -O2 -Wundef > > -Wimplicit-function-declaration -mcpu=i586 -c -o w32misc.o > > w32/subproc/misc.c gcc.exe: w32/subproc/misc.c: No such file or > > directory gcc.exe: No input files > > make[1]: *** [w32misc.o] Error 1 > > > > Analysis: This rule wasn't written in the best way. To keep this build > > portable and GNU-proper all rules must allow building outside the > > source dir (which I generally do but I think John, you may not have > > been). The way I know how to fix this is to rewrite the rule like > > this: > > > > w32misc.o: w32/subproc/misc.c > > $(COMPILE) -c -o w32misc.o $< > > CORRECTION: GNU does not recommend this -- this is wrong (my fix was > wrong). Some 'make' programs won't do this right. It should be, > instead: > > loadavg.c: $(srcdir)/getloadavg.c > cp $(srcdir)/getloadavg.c $@ > > > Which then finds the .c file because the top of the makefile has the > > src dir in VPATH. > > If you're concerned with a portable Makefile, VPATH shouldn't be used either. :) > > (3) The error: > > make[1]: Entering directory > > `/k/WinNT_sees_now/tmpbuilddir/gmakes/make-3.80rc2_build' gcc -O2 > > -Wundef -Wimplicit-function-declaration -mcpu=i586 -o make.exe > > ar.o arscan.o commands.o default.o dir.o expand.o file.o > > function.o getopt.o getopt1.o implicit.o job.o main.o misc.o read.o > > remake.o remote-stub.o rule.o signame.o variable.o version.o > > vpath.o hash.o pathstuff.o dirent.o sub_proc.o w32err.o > > getloadavg.o w32misc.o > > ar.o(.text+0x486)://h/src/make-3.80rc2_patched/ar.c: undefined > > reference to `fnmatch' > > read.o(.text+0x45a6)://h/src/make-3.80rc2_patched/read.c: undefined > > reference to `glob' > > read.o(.text+0x47c9)://h/src/make-3.80rc2_patched/read.c: undefined > > reference to `globfree' make[1]: *** [make.exe] Error 1 > > > > Analysis: This is a basic link-time failure obviously, and is > > connected to (1) above. Because the macro GLOBLIB is empty, no go. An > > entry like the following needs to be in GLOBLIB: > > > > -L$(top_builddir)/glob -lglob > > As per above, this was a major issue (because I decided to make it one > ;-). > So, the real problem for this is Soren, or something else? Earnie. |
From: Greg C. <chi...@mi...> - 2002-09-25 02:36:24
|
Earnie Boyd wrote: > > Soren A wrote: > > > > > (2) The error: > > > make[1]: Entering directory > > > `/k/WinNT_sees_now/tmpbuilddir/gmakes/make-3.80rc2_build' gcc [snip many defines and flags] > > > -c -o w32misc.o > > > w32/subproc/misc.c gcc.exe: w32/subproc/misc.c: No such file or > > > directory gcc.exe: No input files > > > make[1]: *** [w32misc.o] Error 1 > > > > > > Analysis: This rule wasn't written in the best way. To keep this build > > > portable and GNU-proper all rules must allow building outside the > > > source dir (which I generally do but I think John, you may not have > > > been). The way I know how to fix this is to rewrite the rule like > > > this: > > > > > > w32misc.o: w32/subproc/misc.c > > > $(COMPILE) -c -o w32misc.o $< > > > > CORRECTION: GNU does not recommend this -- this is wrong (my fix was > > wrong). Some 'make' programs won't do this right. It should be, > > instead: > > > > loadavg.c: $(srcdir)/getloadavg.c > > cp $(srcdir)/getloadavg.c $@ > > > > > Which then finds the .c file because the top of the makefile has the > > > src dir in VPATH. > > If you're concerned with a portable Makefile, VPATH shouldn't be used > either. :) I assume you mean that VPATH's directory separator is a semicolon for windows, but a colon otherwise. But you can work around that by using vpath, e.g. vpath % $(srcdir) vpath % $(extra_path_0) vpath % $(extra_path_1) instead of VPATH = $(srcdir);$(extra_path_0);$(extra_path_1) |
From: Earnie B. <ear...@ya...> - 2002-09-25 03:16:47
|
Greg Chicares wrote: > > Earnie Boyd wrote: > > > > Soren A wrote: > > > > > > > (2) The error: > > > > make[1]: Entering directory > > > > `/k/WinNT_sees_now/tmpbuilddir/gmakes/make-3.80rc2_build' gcc > [snip many defines and flags] > > > > -c -o w32misc.o > > > > w32/subproc/misc.c gcc.exe: w32/subproc/misc.c: No such file or > > > > directory gcc.exe: No input files > > > > make[1]: *** [w32misc.o] Error 1 > > > > > > > > Analysis: This rule wasn't written in the best way. To keep this build > > > > portable and GNU-proper all rules must allow building outside the > > > > source dir (which I generally do but I think John, you may not have > > > > been). The way I know how to fix this is to rewrite the rule like > > > > this: > > > > > > > > w32misc.o: w32/subproc/misc.c > > > > $(COMPILE) -c -o w32misc.o $< > > > > > > CORRECTION: GNU does not recommend this -- this is wrong (my fix was > > > wrong). Some 'make' programs won't do this right. It should be, > > > instead: > > > > > > loadavg.c: $(srcdir)/getloadavg.c > > > cp $(srcdir)/getloadavg.c $@ > > > > > > > Which then finds the .c file because the top of the makefile has the > > > > src dir in VPATH. > > > > If you're concerned with a portable Makefile, VPATH shouldn't be used > > either. :) > > I assume you mean that VPATH's directory separator > is a semicolon for windows, but a colon otherwise. > But you can work around that by using vpath, e.g. > > vpath % $(srcdir) > vpath % $(extra_path_0) > vpath % $(extra_path_1) > > instead of > > VPATH = $(srcdir);$(extra_path_0);$(extra_path_1) > No, Soren had made mention of portable Makefile for use by some other make besides gmake. VPATH isn't portable for this situation. Earnie. |
From: Paul D. S. <ps...@gn...> - 2002-09-25 04:15:33
|
%% Earnie Boyd <ear...@ya...> writes: eb> No, Soren had made mention of portable Makefile for use by some eb> other make besides gmake. VPATH isn't portable for this eb> situation. True, but just having the variable VPATH set in your makefile doesn't _hurt_ anything. It's just another unused variable. This is why we recommend using VPATH wherever possible: using the vpath syntax is GNU make specific and a syntax error in other versions of make. You just can't get the benefit of compiling in other directories if you don't use GNU make (or at least a make that has "sane" VPATH characteristics), but compiling in the same directory still works. -- ------------------------------------------------------------------------------- Paul D. Smith <ps...@gn...> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist |
From: Soren A <sor...@fa...> - 2002-09-25 04:50:46
|
"Paul D. Smith" <ps...@gn...> wrote around 25 Sep 2002 news:157...@le...: > It's just another unused variable. This is why we recommend using > VPATH wherever possible: using the vpath syntax is GNU make specific > and a syntax error in other versions of make. > > You just can't get the benefit of compiling in other directories if you > don't use GNU make (or at least a make that has "sane" VPATH > characteristics), but compiling in the same directory still works. Yes, thanks Paul, you had the patience to explain and I am completely out of it. Not only "we recommend" but in fact it is *built in* to Automake to create a VPATH entry. Oh, and as you noted, GNU 'make' is not the only 'make' that understands VPATH. Best, Soren A |
From: Paul D. S. <ps...@gn...> - 2002-09-25 17:27:36
|
%% Soren A <sor...@fa...> writes: sa> Oh, and as you noted, GNU 'make' is not the only 'make' that sa> understands VPATH. Correct, although in most other versions of make VPATH is not that useful. Consider: VPATH only modified automatic variables. But in most makes (as you pointed out earlier) most of the automatic variables, like $< etc., are not defined in explicit rules. So.... you can't use VPATH in conjunction with explicit rules! How bogus is that? Anyway, that particular problem doesn't exist with automake generated files since they don't use non-portable syntax like $< in explicit rules anyway. But, there are still other issues. Nevertheless, it might work with some other SysV makes... sometimes... -- ------------------------------------------------------------------------------- Paul D. Smith <ps...@gn...> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist |
From: Soren A <sor...@fa...> - 2002-09-25 18:00:44
|
"Paul D. Smith" <ps...@gn...> wrote around 25 Sep 2002 news:157...@le...: > %% Soren A <sor...@fa...> writes: > > sa> Oh, and as you noted, GNU 'make' is not the only 'make' that > sa> understands VPATH. > > Correct, although in most other versions of make VPATH is not that > useful. Consider: VPATH only modified automatic variables. But in most > makes (as you pointed out earlier) most of the automatic variables, like > $< etc., are not defined in explicit rules. > > So.... you can't use VPATH in conjunction with explicit rules! How > bogus is that? WAY bogus! ;-). I cannot believe that. Is that some lame attempt to make their 'make' look like it's comparable to GNU's, or what? And I thought only M$ was prone to that sort of fake-feature-fluff. SillyByGosh. :-) Soren A |
From: Paul D. S. <ps...@gn...> - 2002-09-25 17:55:29
|
%% Soren A <sor...@fa...> writes: >> Correct, although in most other versions of make VPATH is not that >> useful. Consider: VPATH only modified automatic variables. But in most >> makes (as you pointed out earlier) most of the automatic variables, like >> $< etc., are not defined in explicit rules. >> >> So.... you can't use VPATH in conjunction with explicit rules! How >> bogus is that? sa> WAY bogus! ;-). I cannot believe that. Is that some lame attempt sa> to make their 'make' look like it's comparable to GNU's, or what? sa> And I thought only M$ was prone to that sort of sa> fake-feature-fluff. SillyByGosh. Actually, VPATH was first invented in SysV make. They just didn't do a very good job of it (IMO anyway). I guess it's still useful if all you use is suffix rules--but that's pretty limited definition of useful. -- ------------------------------------------------------------------------------- Paul D. Smith <ps...@gn...> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist |
From: Earnie B. <ear...@ya...> - 2002-09-25 12:27:10
|
"Paul D. Smith" wrote: > > %% Earnie Boyd <ear...@ya...> writes: > > eb> No, Soren had made mention of portable Makefile for use by some > eb> other make besides gmake. VPATH isn't portable for this > eb> situation. > > True, but just having the variable VPATH set in your makefile doesn't > _hurt_ anything. It's just another unused variable. This is why we > recommend using VPATH wherever possible: using the vpath syntax is GNU > make specific and a syntax error in other versions of make. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Yes, so, if you're concerned about being portable with multiple vendors of make then dependency with VPATH operation makes it non-portable. > > You just can't get the benefit of compiling in other directories if you > don't use GNU make (or at least a make that has "sane" VPATH > characteristics), but compiling in the same directory still works. > I'm all for using VPATH, and if some vendor make doesn't work I always replace it. I'm not arguing about not using VPATH. My argument is to "if some vendor make doesn't work, replace it with what does." Gmake is freely available. Earnie. |
From: Paul D. S. <ps...@gn...> - 2002-09-25 14:30:24
|
%% Earnie Boyd <ear...@ya...> writes: >> True, but just having the variable VPATH set in your makefile doesn't >> _hurt_ anything. It's just another unused variable. This is why we >> recommend using VPATH wherever possible: using the vpath syntax is GNU >> make specific and a syntax error in other versions of make. eb> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ eb> Yes, so, if you're concerned about being portable with multiple eb> vendors of make then dependency with VPATH operation makes it eb> non-portable. Note I said that "vpath" (lowercase) creates a syntax error, because the format is: vpath <pattern> <pathlist> which is a syntax error in standard make. VPATH (uppercase) is just a variable setting: VPATH = <pathlist> so if you use it in a makefile and the make you use doesn't handle VPATH, it's just treated as a normal variable with no special characteristics. Obviously you're correct in that if your makefile _requires_ VPATH behavior or it won't work, then this is not going to help. But the GNU makefiles (at least those generated by automake) are very carefully constructed so that they will work without VPATH support, if you build in the source directory. So, using VPATH here does _not_ make those makefiles non-portable, it just means you don't have as many options as you would if you did use GNU make. If you want to build outside the source directory, _then_ you need a make which understands VPATH and gives it mostly the same semantics as GNU make does. Probably everyone reading this understands all this perfectly well and I'm just beating a dead horse so... I'll be quite now :). -- ------------------------------------------------------------------------------- Paul D. Smith <ps...@gn...> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist |
From: Soren A <sor...@fa...> - 2002-09-25 17:33:45
|
"Paul D. Smith" <ps...@gn...> wrote around 25 Sep 2002 news:157...@le...: > Probably everyone reading this understands all this perfectly well and > I'm just beating a dead horse so... I'll be quite now :). I am quite sure that not everyone reading right now and also later (especially now that this List and others are hooked up with Gmane so they can look like newsgroups and be searched readily) understood the issue you have explained clearly, if at all. There are always newbies about and VPATH and it's purposes is far from intuitive for newbies. Also I want at this time to plug Paul's Website: http://www.paulandlesley.org/make/multi-arch.html which will open the eyes of some who read it. Paul's system for using GNU make is very ingenious and slick. Highly recommended. Even some old-timers who think they have their own system 'down pat' may find themselves 'converted' to a better way. I'll also, for orthogonality, plug my own website now: http://home.att.net/~perlspinr/makefiles/makefileworkshop.html Best, Soren A |
From: Soren A <sor...@fa...> - 2002-09-25 17:51:14
|
Earnie Boyd <ear...@ya...> wrote around 25 Sep 2002 news:3D9...@ya...: > I'm all for using VPATH, and if some vendor make doesn't work I always > replace it. I'm not arguing about not using VPATH. My argument is to > "if some vendor make doesn't work, replace it with what does." Gmake is > freely available. On this point i agree heartily with you. Aside from the clarification of the misunderstanding concerning "portability" that Paul's next follow-up discusses, i find it silly and stubborn when people complain that their 'make' won't do a GNU Makefile right. I've been flogging that horse over on the PNG-Implement List and boy are those folks stubborn ;-). Nonetheless partly because of that I am now making an effort to learn what some *nix-standard 'make's do and don't do -- like a 'make' I'd find supplied by the vendors of an SGI system or a Sun system. If anyone knows about some resources to look at in this regard I'd appreciate hearing about it. Aside from the GNU 'make' manual, that is, which has a very good section which explains which features of GNU make are unique to it. Best, Soren |
From: Soren A <sor...@fa...> - 2002-09-25 04:37:14
|
Earnie Boyd <ear...@ya...> wrote around 24 Sep 2002 news:3D9...@ya...: > No, Soren had made mention of portable Makefile for use by some other > make besides gmake. VPATH isn't portable for this situation. No. None of the above. All completely whack. Rewind; erase. The criticism concerning VPATH was completely based on ignorance -- your's, Earnie. There is something about how GNU configure scripts work that you aren't aware of. I wasn't writing about using VPATH in any non-portable manner, or of causing VPATH to be introduced into build configuration files where they are not *always* placed routinely by GNU autotool-based 'configure's. I suggest you realize that you didn't understand what I was talking about and just took "VPATH" as a red flag. I also suggest if you still have questions, not challenging me to explain this further. Merely running any reasonable Autotools-based package 'configure' in a separate build dir from where the 'configure' script itself is located (along with all the package source files), and then opening up the Makefile in a text editor and looking within the first 10 or so lines from the top of the file, is the recommended starting place to embark on discovering this aspect of GNU-standard build configuration. I didn't invent it (GNU-standard) and I am working extra-hard to conform to it. I won't engage here in discussions defending it either. Goodnight, Soren |
From: Soren A <sor...@fa...> - 2002-09-25 04:24:06
|
Earnie Boyd <ear...@ya...> wrote around 24 Sep 2002 news:3D9...@ya...: > So, the real problem for this is Soren, or something else? In a bad mood tonight, Earnie? This, what I have been posting, is very useful information for somebody who is actually trying to collboratively work on porting issues with GNU make. It's the guts, the details, the substance. If you are tired or not interested right now, you really don't have to answer. But whatever you do, PLEASE do not turn into cgf and start senselessly, thoughtlessly, carelessly discouraging people are just doing exactly what "hard volunteer work" means. If you don't like something about the style, that's fine but that's just you. John Cronin posted detailed patches and reports about how far he had gotten. I spent 10+ hours re-creating his setup painstakingly and then began testing. I ran into problems right away. I believe this process is called "beta testing" and "debugging." Where I am at right now is that I have got John's changes "hardened" (robustified), based on that real work and not on dogma or commmentary offered while sitting far overhead with a pair of binoculars and a cocktail in the other hand while I am really only mostly watching a ballgame on TV. I know my articles are weird to look at because as far as I can tell, this nearly never happens with MinGW or Cygwin or anywhere else. Face it. The hackers who comprise Us are largely a lot of wanna-be alpha dogs who, once we smell that another dog has pissed extensively over some turf, lose interest (because we want to stake out fresh ground of our own). I for one know that this is a rather counter-productive (if not outright stupid) aspect of human nature that gets in the way of getting the highest-quality results. I more or less *beg* people on OSS Lists to review my work and give me feedback *based on actually downloading a patch and running a build* (not on a quick look-over which results in wasted bandwidth and misunderstandings multiplied). I almost never get that no matter how emphatically I ask. I can live with that -- it just means my results will be more fragile and slower to complete. I "get it" that programmers are highly egotistical about their work and want it to be as individual, creative, singular and unshared with others as possible. We get most stoked about the project which we ourselves as individuals create single-handed from start to finish, so that it has only our own name on it. That's the underlying factor that sets our prioritization (that, and maybe "how many people are howling complaints about a certain bug" in a project we've already released). I believe in putting out what I want to be getting back. In recognition of John's making the efforts he did, I wanted to respond with the most detailed and substantial feedback I could. It only makes sense to do so on-List because that way someone else (a third person) may get in on the game too. When the guys a few years ago announced to the world that they had achieved "Cold Fusion", what happened was that people with no commitment to rigorous scientific rationality (for example: journalists) got all exercized over it. Then eventually teams got set up to try and reproduce their results. We all know how that turned out. What i've been doing with John's contributed patch was nothing other than this, in essence: methodically try to reproduce his results and then try to expand the description of what parameters may impact on being able to do so, for others to come in the future. Debugging. Engineering -- as in "software engineering" -- is an applied scientific discipline. It is not distinctinctly different from science in method, only in goals (the goal of 'pure' science being to further human theoretical knowledge about some aspec tof the Universe, while the goal of engineering is to build something concrete that does something useful). I am not the least bit concerned about revealing my stupid mistakes, lack of knowledge or misconceptions about something "in public" because this is real trial-and-error learning. Others who may not be as expert as you (or as me) can see what I am doing step by painful step and learn about the process from that. Those who may be interested in helping to achieve the stated goal (of merging in all needed changes to get a robust MinGW 'make' buildable without kludges from mainline GNU 'make' source in the future) can extract from the detailed reports a more accurate picture of what issues remain to be resolved, in case (as is very likely with all human beings as opposed to automata [but only when their programming is utterly free of bugs, which is seldom or never]) I err in how I document, explain or describe something. What I *am* absolutely confident about is my powers of concentration and my determination. There are lots of bright people around. Lots of them don't follow through on things a lot. You'll see the kind I mean all over, and not just in OSS communities. They are all too ready to open up their mouths and talk down somebody elses' work or ideas based on fabulously detailed theoretical understanding of many fields of human knowledge. But when it comes to producing something (besides hot air) of actually *use* or *value* to others, they mysteriously disappear. Such people cannot close the gap between talk and concrete result because they lack something that isn't about "intelligence" at all but about that almost extinct concept called "human character". I think the quality of "robustness" in software is a reflection of the person or people who developed it. I think when it's fragile, when it breaks very easily if everything isn't set up just-so, that's a reflection of the person who wrote it: they just didn't have the stamina, determination, concentration or gumption to stick with the tiresome, tedious task of endlessly (it feels like) checking and re-checking the work. I have a setup that is less than perfect and that's a GOOD thing because it means that when a development project lands on MY hard drive, it's in for some real-world (as opposed to theoretical fairyland) banging-about. I am working on Win98 tonight, not even WindowsNT, for instance. I'll post a url for the 'configure.in' file now that I am pretty satisfied with it as far as addressing all the issues that I turned up. http://home.att.net/~perlspinr/build_platforms/mingw- make/configure_in.html And the Makefile.am to go with it is at http://home.att.net/~perlspinr/build_platforms/mingw- make/Makefile_am.html Later on I will post a url for a diff. I already posted previously in refutation of the view that 'working on build configuration files isn't "real contribution".' I will repeat it in somewhat less detail and tact now: Hacking autotool'ed build configuration files *isn't trivial* and anyone who claims it is and on that basis, disses the efforts of another, is about 1/2 as smart as they think they are (and may want us to think they are). Best Regards, Soren A |