Problem with building .info files?
The rule for building .info files from .texi files looks incorrect to me: .texinfo.info: restore=: backupdir=$(am__leading_dot)am \ am__cwd=`pwd` cd $(srcdir) \ rm -rf $$backupdir mkdir $$backupdir \ [...] It seems to me that cd'ing into $(srcdir) and mucking around in there is inappropriate: what if the source tree is on some read-only media, or we don't have write privs to it, or whatever? Shouldn't these backups be kept in the build directory? In general the scripting of this rule seems dodgy in a number of ways... but maybe there's something special about makeinfo or whatever that mandates it? -- --- Paul D. Smith [EMAIL PROTECTED] 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
Re: Cover Texts in the automake documentation
%% Russ Allbery [EMAIL PROTECTED] writes: ra Alexandre Duret-Lutz [EMAIL PROTECTED] writes: Eric: | Is there any way you might consider dropping the | Front and Back Cover Texts requirements from the manual? Sorry, this is the FSF policy. Not my call. ra There are other GNU packages with GFDL manuals that do not have ra Front and Back Cover Texts, so it's clearly not a mandatory ra policy. Unfortunately, the rest of us aren't really in a position ra to talk to the right people to get this changed, whereas the ra official Automake maintainers would be. Could you try? It's my understanding (and I'm in no way speaking for the FSF here) that if the manual is published by the FSF as a book, with an ISBN etc., it has to have these front and back cover texts. Those texts only exist in the printed forms of the manual (since the front and back covers referred to by the texts only exist in printed forms of the manual). However, I have no idea whether or not this is a mandatory requirement for all GNU packages with published manuals. -- --- Paul D. Smith [EMAIL PROTECTED] 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
Re: I: adjust test suite for upcoming GNU Make 3.83
%% Alexandre Duret-Lutz [EMAIL PROTECTED] writes: adl So any solution that require a syntax that is different in adl prerequisites than it is in the commands seems wrong to me. pds I definitely agree that this incongruity is disturbing, but pds that's the way it is. adl Don't read me wrong, that wasn't a judgement of the way things adl are but an attempt to characterize an acceptable solution for adl Automake. Automake is meant to produce portable Makefiles so I adl don't want to introduce non-portable constructs in its generated adl output, even conditionally (it's already hard enough to test). adl The only place we could tolerate non-portable constructs is in adl the user input (*.am) that is output almost verbatim. Hence my adl statement: since users writes the variables, I'm looking for a adl solution that involves only changing these variables, and since adl these variables are used both in prerequisite lists and adl commands... I definitely understand your concern. All I can say is that filenames with $ in them (and so, in effect, any support of Java IIRC) is already completely non-portable. I guess the problem is that it used to be non-portable in that it wouldn't work correctly, but at least the output makefile was a valid makefile for all versions of make. Now, if we want to support backward-compatibility, you'd need to put some code into the makefile which is valid make syntax only in GNU make... which means you'd have to forgo even printing it into a makefile unless you knew it was needed. Hm. Or, do you? This actually should be valid make syntax in all versions of make: PRE_D = $(if $(filter second-expansion,$(.FEATURES)),,$$) FILENAMES = foo$$bar all: $(subst $$,$(PRE_D),$(FILENAMES)) @echo 'FILENAMES = $(FILENAMES)' @echo '$@ : $^' foo$$bar: @echo 'touch $@' Now, obviously, it won't WORK properly with any make other than GNU make, but at least the syntax is valid POSIX make syntax. The other problem of course, is that you can't use the subst function in every makefile for every prerequisite: you'd need to figure out which makefiles might have $ in the prerequisite lists and only use it there. So, it's still gross. The other alternative is to do away with backward compatibility and just say that as of release automake XXX you need GNU make 3.81 if your makefiles have $ in the names. The nice(?) thing about this is that these makefiles should also, then, work with other SysV make versions. Or, you can have an automake option that selects which the user has. Or test for it, although of course that's not very reliable. Bleah. I see no good solution to this. pds Hopefully the next version of GNU make will have some more generic pds mechanism for quoting that will handle ALL different special pds characters that might appear in filenames, including colons and pds whitespace as well as dollar signs. adl Excellent! That seems to be the ticket, doesn't it? Well, sure, but that won't help us between the time 3.81 is released and the time the version with the quoting enhancement is released. I'd really hate to have to tell people they couldn't use 3.81 with automake. I guess it would only impact users with $ in filenames but still... And, of course, that syntax won't be portable either :-/. -- --- Paul D. Smith [EMAIL PROTECTED] 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
Re: I: adjust test suite for upcoming GNU Make 3.83
Hi all; I got no real response to this. This release of GNU make (3.81) is coming up (one hopes!) and this seems like a real problem that we need to come up with a solution for. If we don't it seems like automake and GNU make 3.81 and Java simply will not be usable together. Anyone have any thoughts or opinions on this? Reminding you; from the NEWS file for 3.81beta3: ftp://alpha.gnu.org/gnu/make/make-3.81beta3.tar.bz2 * WARNING: Backward-incompatibility! GNU make now implements a generic second expansion feature on the prerequisites of both explicit and implicit (pattern) targets. After the rule has been parsed, the prerequisites are expanded a second time, this time with all the automatic variables in scope. This means that in addition to using standard SysV $$@ in prerequisites lists, you can also use complex functions such as $$(notdir $$@) etc. This behavior applies to implicit rules, as well, where the second expansion occurs after the rule is matched. However, this means that you need to double-quote any $ in your filenames; instead of foo: boo$$bar you must write foo: foobar. Since we last spoke, however, there has been a new feature added which may help somewhat: * New special variables available in this release: - .FEATURES: Contains a list of special features available in this version of GNU make. One of the words in the .FEATURES list will be second-expansion if this feature is present. However, I see no way to take advantage of this that is compatible with non-GNU versions of make. I don't know whether automake currently works correctly for Java with any other version of make, but this would definitely cause that not to be the case going forward. -- --- Paul D. Smith [EMAIL PROTECTED] 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
Re: I: adjust test suite for upcoming GNU Make 3.83
FYI, here's one way to handle it (obviously requires GNU make): ifeq (,$(filter second-expansion,$(.FEATURES))) # GNU make 3.81 PRE_D := $$ else # GNU make =3.81 PRE_D := endif # Now use PRE_D in prerequisites all: foo$(PRE_D)bar ; @echo '$@: $' foo$$bar: ; @echo 'building $@' -- --- Paul D. Smith [EMAIL PROTECTED] 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
Re: Error because README is missing
%% Alexandre Duret-Lutz [EMAIL PROTECTED] writes: adl Hi Paul, Paul == Paul Smith [EMAIL PROTECTED] writes: Paul In the GNU make package I don't have a README file when Paul it is first checked out from CVS. Paul This used to work but now automake is failing: adl What version(s) used to work, and which one is failing? I'm not sure which ones used to work, but I know 1.8 and 1.9 both fail. I think what used to happen is I would get warnings, but automake would still succeed so I could just ignore the warning and continue on, and by the time I actually got around to building a distribution everything would be fine. Paul There is a README.in which is translated into a README, Paul replacing the version info etc. adl When and how? This turns out to be the key question. My setup is a little odd; I'm willing to change/fix it if someone can suggest a better way to do what I'm doing. The README file is created with a makefile target, but it isn't in Makefile.am (see the description below). I actually solved the README problem by putting a dummy target in my Makefile.am, like this: README: Now automake doesn't complain about this anymore. However, I actually had a second error that I didn't mention because I figured it would be the same problem... but it's not. The second error is this: $ automake --add-missing --no-force configure.in:398: required file `build.sh.in' not found This file is being created with this in my configure.in file: if test -f $srcdir/build.sh.in; then AC_CONFIG_FILES(build.sh) fi Adding an empty target for build.sh.in into Makefile.am doesn't help in this situation, I guess because it's referenced in configure.in, not Makefile.am. Is there any way to get automake to work in this situation? --- What I have is a Makefile.am that's pretty straightforward. Then at the bottom of that file I have: @MAINT_MAKEFILE@ I also have a file maintMakefile which contains a bunch of maintainer-only rules for building GNU make from CVS, etc., and this makefile is written in non-portable GNU make. The Makefile.am does _NOT_ list the maintMakefile in the list of files to be distributed, so when I create a dist tarball it's not there. In configure.in I have some text like this: # Include the Maintainer's Makefile section, if it's here. MAINT_MAKEFILE=/dev/null if test -r $srcdir/maintMakefile; then MAINT_MAKEFILE=$srcdir/maintMakefile fi AC_SUBST_FILE(MAINT_MAKEFILE) The goal behind this is: * Allows me to write some complex rules using GNU make features. * Allows maintainer-only targets to be automatically added to the makefile when you have a CVS version, but automatically _NOT_ added to the makefile when you're building a real distribution. * You need GNU make to build from CVS, but not to build a dist tarball. The problem is that the rule to build the README file is in the maintMakefile, not in the Makefile.am. As an experiment I moved it to Makefile.am and sure enough, my error went away. -- --- Paul D. Smith [EMAIL PROTECTED] HASMAT--HA Software Mthds Tools Please remain calm...I may be mad, but I am a professional. --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them.
Re: automake -vs- huge projects
%% Bob Friesenhahn [EMAIL PROTECTED] writes: So, IMO, for being useful, you'd either have to extend make to accept the *.am-syntax or to reimplement make. bf Exactly. The binary 'automake' would be a plain make which also bf understands Automake syntax. bf If a non-standard tool is required to be on the user's system in order bf to build software, then it might as well be a tool that does bf everything. :-) If you're willing to require GNU make then I'm quite confidant you could write automake as nothing more than a suite of GNU make macros and functions. I doubt there would be any need for code changes to GNU make at all. -- --- Paul D. Smith [EMAIL PROTECTED] 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
Re: automake -vs- huge projects
%% Lars Hecking [EMAIL PROTECTED] writes: lh What about an automake option then to generate Makefiles for GNU lh make? You might get slightly more takers for an option to allow use of pattern rules, without specifically tying them to GNU make or relying on other _very_ GNU make-centric features. I think there are several versions of make that support pattern rules. -- --- Paul D. Smith [EMAIL PROTECTED] 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
Re: automake -vs- huge projects
%% Bob Friesenhahn [EMAIL PROTECTED] writes: bf Per-subdirectory rules and definitions can be added in order to bf significantly reduce the amount of redundant code, and to bf re-enable the capability to usefully override parts of the default bf Makefile.in. Not if you want to continue to generate portable makefiles. There is no way in POSIX make (for example) to generate a target in a subdirectory using a suffix rule. -- --- Paul D. Smith [EMAIL PROTECTED] 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
Re: automake 1.7d feedback
%% Bruno Haible [EMAIL PROTECTED] writes: bh automake-1.7d is fine for me: I cannot find anything wrong with it. bh However, there is an important change in behaviour that IMO should bh be mentioned in the NEWS file (or maybe even undone): While it was bh possible to add dependencies to automake targets in bh automake-1.7.x, such dependencies are now interpreted as bh *overriding* the automake definition. In usual Makefiles, when I bh write bhtarget: dependencies bh RULES bh then it overrides the original target definition if and only if the bh RULES section is nonempty. This is a pitfall for users: While the bh syntax of Makefile.am is the same as the syntax of Makefiles, bh writing a line like bhtarget: dependencies bh doesn't mean the same thing. Speaking from the peanut gallery, with my GNU make hat on, I'd say this is a bug. I think it's important for automake to preserve standard make functionality, at least in this very basic situation. It's often extremely useful to be able to separate the prerequisite definition from the command script definition. -- --- Paul D. Smith [EMAIL PROTECTED] 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
Re: Help - I'm going mad!!! /bin/bash: --gnu: command not found
%% Dr. David Kirkby [EMAIL PROTECTED] writes: dk make[1]: Entering directory `/export/home/davek/atlc/src' dk cd .. \ dk--gnu src/Makefile dk /bin/bash: --gnu: command not found dk /bin/bash does exist by the way, but seems unwillig to accept the dk --gnu option. Nope, that's not what this means. The error is not _about_ bash, it's being generated _by_ bash. Look more closely at the command line you're running: extracting the backslash it's: cd .. --gnu src/Makefile That tells the shell it should cd to .., then if that succeeds run the program after the , which is --gnu, with an argument src/Makefile. There is no program --gnu on your system, so bash reports this error: --gnu: command not found It seems pretty obvious that there's something missing in this command line. Probably in the makefile there's a variable there that's supposed to hold the name of the command, but for some reason it contains no value so it's being expanded to the empty string. That's about all I can tell you at this point, but you can stop going mad about this particular message now, at least! :) -- --- Paul D. Smith [EMAIL PROTECTED] 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
Re: config.sub, config.guess, and the GNU FTP site
%% Paul Eggert [EMAIL PROTECTED] writes: pe Ben, would you like to have checkin privileges to gnulib? pe Then you can simply install the latest versions there. In another message, John Eaton seems to imply that there's already a config Savannah project that contains these files in CVS. In fact, I can find it there now that I know about it :). -- --- Paul D. Smith [EMAIL PROTECTED] 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
Re: GNU ftp crack and config.{sub,guess}
%% Russell Shaw [EMAIL PROTECTED] writes: rs Paul D. Smith wrote: I'm still waiting for _ANY_ kind of response here. Doesn't anyone know or care about config.guess or config.sub anymore? rs From automake manual: rs config.guess rs config.sub rs These programs compute the canonical triplets for the given build, rs host, or target architecture. These programs are updated regularly rs to support new architectures and fix probes broken by changes in rs new kernel versions. You are encouraged to fetch the latest rs versions of these files from ftp://ftp.gnu.org/gnu/config before rs making a release. Yep, but if you read the rest of my message you'll see that the files on ftp.gnu.org are not actually there: they were removed when the system was cracked and they have not been replaced yet. So, I'm looking for a new place to get the latest versions from. rs locate config.guess rs... rs/usr/share/doc/config.guess When I release a GNU program I don't want to use whatever random versions I happen to have lying around on my system. I want the latest stuff. -- --- Paul D. Smith [EMAIL PROTECTED] 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
Re: GNU ftp crack and config.{sub,guess}
I'm still waiting for _ANY_ kind of response here. Doesn't anyone know or care about config.guess or config.sub anymore? %% [EMAIL PROTECTED] writes: p Hi Ben; p I've been trying to build GNU make packages. Like some of the other GNU p toolkits, my make dist process involves a wget of the very latest p config.guess and config.sub files from the ftp.gnu.org server. p Unfortunately right now this doesn't work: when the ftp.gnu.org server p was cracked they pulled all the source off of it until it could be p verified to be correct. Most of the content has been replaced by p now, but these two files (from ftp.gnu.org/gnu/config/) are still not p there, so my make dist operations are failing :(. I can work around p this by installing older versions by hand but I'd like to see the real p stuff available again. p I checked with the GNU folks and they would like you to provide them p with known-good (say, from CVS) copies of the proper versions of these p files, but haven't been able to get in touch with you. p Do you know anything about this? p Or, does anyone on the autoconf list know how we'd go about getting the p proper versions loaded onto ftp.gnu.org again? -- --- Paul D. Smith [EMAIL PROTECTED] 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
Removing MAKE = make setting
Hi all; The makefiles generated by automake always contain this line: MAKE = make Well, this is a bummer for my use of automake (which is to build GNU make itself); this line causes all sorts of problems. Is there any way to keep automake from generating this line, or any way to work around this anyone can think of? Thanks! -- --- Paul D. Smith [EMAIL PROTECTED] 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
Problems with ansi2knr
Hi all; I'm using automake 1.7 (with autoconf 2.54 and gettext 0.11.5). I'm trying to add ansi2knr support so I can use ANSI function definitions in GNU make. I have special code to test the getloadavg.c, which builds a test program using that code. The test program is embedded in the file, and enabled with a -DTEST to get a main(), etc. I have this in my Makefile.am: AUTOMAKE_OPTIONS = 1.7 dist-bzip2 check-news ansi2knr ... # The loadavg function is invoked during make check to test getloadavg. noinst_PROGRAMS = loadavg nodist_loadavg_SOURCES = loadavg.c loadavg_CFLAGS = -DTEST loadavg_LDADD = @GETLOADAVG_LIBS@ loadavg.c: $(srcdir)/getloadavg.c cp $(srcdir)/getloadavg.c loadavg.c This works for normal builds, but fails during builds without ANSI compilers. The problem is that when the rules to build loadavg-loadavg.o are created, they depend on just loadavg.c, instead of loadavg$U.c. For example: loadavg-loadavg$U.$(OBJEXT): loadavg.c ... loadavg-loadavg$U.o: loadavg.c # if $(CC) $(DEFS) ... source='loadavg.c' object='loadavg-loadavg$U.o' libtool=no \ ... I have a rule that constructs a loadavg_.c from loadavg.c: loadavg_.c: loadavg.c $(ANSI2KNR) $(CPP) $(DEFS) $(DEFAULT_INCLUDES) [...] but it's never being invoked because the ...$U.o depends on the plain c instead of the ...$U.c. Help? -- --- Paul D. Smith [EMAIL PROTECTED] 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
Automake vs. autoheader: config.h.in
Hi Tom et. al.: I'm working on a trivial doc to include with GNU make that gives the exact steps to build it from a clean checkout. I based the algorithm on what autoreconf uses, but I can't use autoreconf (mainly due to gettextize issues). So, autoreconf basically proceeds in this order: gettextize, aclocal, automake, autoconf, autoheader. The problem I have is that I have no config.h.in file of my own. So, until the last step (autoheader) there is no config.h.in file in my directory. This means that when automake is run as the third step, it complains about a missing config.h.in (which isn't so bad), and it doesn't add config.h.in to the list of common DISTFILES (which _is_ so bad). So, my question is is this a problem with autoreconf in that autoheader should be run earlier? Or is it a fundamental circularity in the toolchain, and we just need to run one or the other twice (probably run autoheader before automake, then run it again after autoconf to pick up any changes autoconf made, for example)? Or should I ignore the whole problem and add config.h.in to my list of explicit extra dist files? -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://www.paulandlesley.org/gmake/ Please remain calm...I may be mad, but I am a professional. --Mad Scientist
Re: Two issues with automake
%% Akim Demaille [EMAIL PROTECTED] writes: ad | 1) I had a line like this in my configure.in: ad | test -f somefile.in AC_OUTPUT(somefile) ad Err, I suppose you mean AC_CONFIG_FILES. Two AC_OUTPUT is not ad supported by Autoconf. Yes, precisely. Anyway, I changed this to the safer but less aesthetically pleasing: if test -f somefile.in; then AC_CONFIG_FILES(somefile) fi and things seem to work fine. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://www.paulandlesley.org/gmake/ Please remain calm...I may be mad, but I am a professional. --Mad Scientist
Re: qeustion about make
%% Mohammad Saleem [EMAIL PROTECTED] writes: ms I am using gnu make 3.79.1. ms I have a question regarding make. My question is that I want to define a ms symbol on command line. How to do with make? ms For example if I want to define MYOBJECT symbol, how to write? ms I even tried with ms prompt make -D MYOBJECT test.c ms didn't work. This is not actually an automake question; you should better address it to [EMAIL PROTECTED] The answer to your question is that the make variable CPPFLAGS is used to hole C preprocessor flags. So, if you want to change or the flags that are passed to the preprocessor, you would override that make variable on the command line, like this: $ make CPPFLAGS='-D MYOBJECT' -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://www.paulandlesley.org/gmake/ Please remain calm...I may be mad, but I am a professional. --Mad Scientist
Re: Use of vpath to build objects in separate directories
%% Regarding Use of vpath to build objects in separate directories; %% Brian Appel [EMAIL PROTECTED] writes: ba I know vpath can be used to cause object files to be written to a ba directory tree separate from the original source. No, it can't. ba In fact, if I run configure in my separate destination directory, ba it builds Makefiles there and I can perform the make there. ba However, suppose I want to be able to initiate the make while in ba the source tree, instead of in the object tree? You can't do that with VPATH. The only way to do it is put full paths to the object directory in your makefiles. You can do this is a relatively automated manner, if you want, so that normal writers of makefiles don't need to see this. But, it has to be there for make to see. ba In the past on this project, this kind of a thing was accomplished ba using a simple script which wrapped gnumake. It would change ba directories from the source tree to the corresponding object tree, ba copy the makefile if necessary, and then run the make in the ba object tree (using vpath so that make would find the source). ba This was rather simple and allowed developers to execute makes ba while editing files without having to remember to change ba directories to where they wanted the object files to go (they ba would just execute the make from the source directory). This will still work, of course. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://www.paulandlesley.org/gmake/ Please remain calm...I may be mad, but I am a professional. --Mad Scientist
Re: Misleading RCS behaviour
%% Ben Elliston [EMAIL PROTECTED] writes: Paul == Paul D Smith [EMAIL PROTECTED] writes: Paul If you need to have the files created in their VPATH-found location Paul instead of in the local directly, use the GPATH variable to specify Paul which directories contain those types of files. Paul See the GNU make manual, and let me know. be OK, this seems better, but it's not used by Automake, so it's not all be that helpful to me. Well, that seems like it might be a bug in automake :). I guess it kind of depends on exactly what you want, but I think you're right that given the way automake works, the GPATH'd behavior for finding the source directory would work better in general. Without GPATH, new files checked out will be placed in the target directory; with it they will be updated in the source directory. However, you can just add: GPATH = $(VPATH) to your Makefile.am files and get the same effect even if automake doesn't support it. Obviously this is an innocuous no-op statement in non-GNU make variants. be By the way -- a documentation bug: GPATH is not in the concept be index. :-) Oops... thanks. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://www.paulandlesley.org/gmake/ Please remain calm...I may be mad, but I am a professional. --Mad Scientist
Re: Fwd: make: you guys are gawds
%% Stephan Beal [EMAIL PROTECTED] writes: sb Please excuse the non-bug post to bug-make@..., but I didn't find sb another address for the make tool, and 'make@' bounced... There's also [EMAIL PROTECTED] FWIW. Thanks for the kudos. Some of this must be attributed to the original inventors of make, though; GNU make added some great new features but GNU didn't invent make itself. sb I now sometimes wonder if automake's output (or even required user sb inputs, like all source and header filenames) couldn't be cut sb drastically by simply taking advantage of more of make's features, The thing is, automake generates makefile which will work with any UNIX make on any system that anyone is using. There is very little that you can assume to be true for all versions of make. Most versions don't have pattern rules (although all have suffix rules); some don't even have include. Most don't allow you to use $ in an explicit rule (!). Etc. There is a POSIX.2 definition of make, but it's very weak (it doesn't have include either, for example), and some makes probably don't even conform 100% to that meager definition. The goal with autoconf/automake is to allow GNU packages to be maintained easily, and with maximum portability. That means they don't want to require that you install GNU make on your system before you can build them, or that you must use GCC as your compiler, etc. etc. Just be happy _you_ don't need to worry about that extreme level of portability, and enjoy GNU make's advanced features :). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://www.paulandlesley.org/gmake/ Please remain calm...I may be mad, but I am a professional. --Mad Scientist
Re: Is alpha.gnu.org down? [Fwd: GNU make 3.79.0.1 pretest released]
%% Free Software Foundation [EMAIL PROTECTED] writes: fsf [CC'ed to a number of lists where it appears the erroneous URL below was fsf published.] I'm trying to retrieve http://alpha.gnu.org/gnu/make/make-3.79.0.1.tar.gz fsf the proper URL is fsf ftp://alpha.gnu.org/gnu/make/make-3.79.0.1.tar.gz, which I have fsf tested, and it does indeed work. Doh! My bad. Thanks for the correction. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://www.paulandlesley.org/gmake/ "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: Changing the name of the PACKAGE at configure time
%% "Masterson, David" [EMAIL PROTECTED] writes: md If you want, I have a Perl tool that I picked up and enhanced md called PKGLINK that could help with this. Basically, with md pkglink, you install all packages in there own prefix directory md and then use pkglink to symbolically link the default version you md want to publish into /usr/local (or someplace similar). The users md only see /usr/local in their PATH(s), but you (the sysadmin) can md control which version is in /usr/local and easily uninstall md packages (simply un-pkglink and remove the package's prefix md directory). There's already a GNU tool called "stow" which does much the same thing, and does handy stuff like automatically making sure you're using the fewest number of symlinks, etc. (e.g., if you have only one version of the tool then stow just puts one symlink to the top of its data directory; if you install a second one it automatically explodes that link into multiple links for the multiple data directories). Stow is cool. We had a discussion about possible enhancements a few months ago, but no real consensus on specific ways to handle the various problems emerged. Fresh insight is always welcome :). -- ------- Paul D. Smith [EMAIL PROTECTED] Network Management Development "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them.
Re: Changing the name of the PACKAGE at configure time
%% Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: "Tom" == Tom Tromey [EMAIL PROTECTED] writes: JMarc What I mean is that I am ready to provide a more "standard" way JMarc of installing several LyX versions concurrently, but does this JMarc standard way exist? Tom Most people just make a new --prefix. jl Well, at my site we have gcc-2.8.1 _and_ gcc-2.95.2, emacs-19.34 _and_ jl emacs-20.2, etc. Yes, but if you ever try to install them you'll see they install as "emacs" and "gcc" by default. jl I thought this was a kind of feature of some GNU tools. Is this jl way of fdoing things deprecated? Not sure what you mean here. Allowing multiple versions to be installed is A Good Thing and is certainly not deprecated. But AFAIK no GNU tools install themselves with version number postfix or similar by default (or at least if they do they always _also_ install as the standard file). I'm with Jean-Marc, though, I wish that automake would add a new standard install target that installed binaries as "name-VERSION" instead of just "name" (for example). Of course, this may not always work for all packages, but... -- ------- Paul D. Smith [EMAIL PROTECTED] Network Management Development "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them.
Need help with Windows port for GNU make (+ DOS pretesters)
Hi all. Recently Rob Tulloh has notified me that he's no longer able to give the maintenance of the Windows port of GNU make the attention he would like, due to other demands on his time. I would like to publicly thank him for his many years of dedication to and support of that effort, and I hope his workload eases in the future so he can spare us some more cycles! :) This leaves us without anyone (AFAIK) on the alpha-test or pre-test lists who is actively supporting or testing the Windows ports. Unfortunately (? ;), I don't have a Windows system that I can even test the build on, much less the expertise to provide code fixes. Indeed, we had some issues with the current 3.79 release on Windows :(. So, if you are interested in helping pretest GNU make on Windows, and/or if you are willing and able to help answer Windows-specific problems (a good number of problems I see are related to Windows shells, etc. and I just don't understand the issues well enough to provide solutions), and/or if you would like to consider Windows-specific enhancements, please let me know. Thanks in advance. BTW, while Eli Zaretskii is still providing excellent support for the DOS port of GNU make, it would be great if we had a few more pretesters for this port, as well. Let me know if you'd like to become a pretester for GNU make. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://www.ultranet.com/~pauld/gmake/ "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
GNU make 3.79 released
[[ Note to pretesters: until the tar file is available on ftp.gnu.org you can access it via ftp://alpha.gnu.org/gnu/make/make-3.79.tar.gz ]] GNU Make version 3.79 is now available for download. The `make' utility automates the process of compilation. When the source files of a large program change, Make automatically determines which pieces need to be updated and recompiles only those files. GNU make is fully compliant with the POSIX.2 standard, and also has many powerful extensions: flexible implicit pattern rules, an extensive set of text manipulation functions, conditional evaluation of makefiles, support for parallel command execution, automatic updating of makefiles, and more. In addition to UNIX systems, it can be built for DOS, Windows (95/98/NT), VMS, and Amiga platforms. This release of GNU make contains several important bug fixes and some new features, including improved flexibility in debugging options. This version also integrates GNU gettext for internationalization support, with at least partial translations for Dutch, French, German, Korean, Polish, Russian, and Spanish. Please see the ABOUT-NLS file for information on enabling internationalization, and for reporting problems with any translations. See the NEWS file and the GNU Make User's Manual, contained in the distribution, for full details on user-visible changes. Please see the README and INSTALL files for information on building GNU make for your system. Bugs and problems should be reported to the [EMAIL PROTECTED] mailing list. Requests for help can be sent to [EMAIL PROTECTED], or one of the gnu.utils.bug or gnu.utils.help USENET newsgroups. See the README file for information on accessing the online bug database, or the latest versions of GNU make via CVS. The complete distribution is available from the GNU ftp site ftp://ftp.gnu.org/gnu/make/ and its mirrors. Please see: http://www.gnu.org/order/ftp.html for a complete list of international mirror sites. No patch file is currently available, since it was over 245k compressed. If you require a patch file please contact [EMAIL PROTECTED]. make-3.79.tar.gz is 959005 bytes MD5 checksum is: a59cc0e5792474f6809131650d2fff5a make-3.79.tar.gz Have fun! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://www.ultranet.com/~pauld/gmake/ "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
