_am_include and _am_quote
I found make command on NEWS-OS 4.2R complains of Makefile.in generated by Automake-1.4h. Makefile.in defines the variables `_am_include' and `_am_quote', but make on that OS cannot handle variable name beginning with `_'. Would you rename the variables? % cat Makefile _am_include = # _am_quote = all:; @echo this is test % make Make: Must be a separator on rules line 2. Stop. % cat Makefile2 am_include = # am_quote = all:; @echo this is test % make -f Makefile2 this is test __ Motoyuki Kasahara
System configuration during install
I am confiscating a large project to autotools. I would like to know if there is a recommended means of adding a daemon to the etc/rc.d/init.d directory and then running chkconfig to add the daemon to run during init. I know how to do it in a script, do the autotools have a specific way it is recommended to add it to make install? David G. Lawrence Smart Technology Enablers, Inc. 1121 Rancho Drive Ojai, CA 93023 (805) 649-6660 (805) 649-6667 fax [EMAIL PROTECTED] www.enablers.com
Re: System configuration during install
Hi, Lawrence, David (STEI) [EMAIL PROTECTED] writes: I am confiscating a large project to autotools. I would like to know if there is a recommended means of adding a daemon to the etc/rc.d/init.d directory and then running chkconfig to add the daemon to run during init. I think thats a lot beyond the scope of Automake. Anyway 'chkconfig' appears to be a Redhat-only tool, and /etc/rc.d/init.d is almost definitely a Redhat peculiarity -- so it isn't the right abstraction if you want your package to be portable, even to other Linux distributions. I know how to do it in a script, do the autotools have a specific way it is recommended to add it to make install? AFAI know, the only system integration that happens on a standard 'make install' is the invocation of 'install-info' to regenerate the 'dir' file in $infodir. You can always put in an 'install-exec-hook' to do the postprocessing. However, I don't think you'll be doing any favours to packagers (like maintainers of RPM or DEB packages). Also, people may not like 'make install' changing the boot-time behaviour of a machine, and/or may not have permissions to modify the boot-time settings. I would suggest putting in a 'setup-boot' target to do this, and ask people to explicitly invoke that rule to integrate your program into the boot setup. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] When all else fails, read the instructions. -- Cahn's Axiom Our policy is, when in doubt, do the right thing. -- Roy L Ash
RE: System configuration during install
Raja, I appreciate and agree with the desire to make a portable source project. That is what I want to do, at least within the various flavors of Linux and Unix. I inherited a project that was Red Hat specific and that is where my non-Windows experience lies. I did not mean to offend by offering the example, I was only trying to outline my desire within the terms I understood best. My understanding (which may be inaccurate) is that Red Hat follows a Unix System V init sequence, so I had felt that having the script used to launch the daemon in /etc/rc.d/init.d and setting up startup and kill entires in the various run levels was at least portable to other System V implementation. I am taking from your response that this is not the case or may be too constraining. If possible, I would like to support the widest range of systems possible with the constraint that I don't as yet understand how they vary. Would you be able to suggest a reference that I could review about portable configuration techniques for adding and removing dameons to a system's initialization process? I would think that other developers of system daemons must have already faced this issue when porting to autotools. Maybe you could also suggest a project I could inspect that needs to perform this function? I appreciate any further insight you can share. Thanks, David G. Lawrence Smart Technology Enablers, Inc. 1121 Rancho Drive Ojai, CA 93023 (805) 649-6660 (805) 649-6667 fax [EMAIL PROTECTED] www.enablers.com -Original Message- From: Raja R Harinath [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 05, 2001 3:33 PM To: Lawrence, David (STEI) Cc: '[EMAIL PROTECTED]' Subject: Re: System configuration during install Hi, Lawrence, David (STEI) [EMAIL PROTECTED] writes: I am confiscating a large project to autotools. I would like to know if there is a recommended means of adding a daemon to the etc/rc.d/init.d directory and then running chkconfig to add the daemon to run during init. I think thats a lot beyond the scope of Automake. Anyway 'chkconfig' appears to be a Redhat-only tool, and /etc/rc.d/init.d is almost definitely a Redhat peculiarity -- so it isn't the right abstraction if you want your package to be portable, even to other Linux distributions. I know how to do it in a script, do the autotools have a specific way it is recommended to add it to make install? AFAI know, the only system integration that happens on a standard 'make install' is the invocation of 'install-info' to regenerate the 'dir' file in $infodir. You can always put in an 'install-exec-hook' to do the postprocessing. However, I don't think you'll be doing any favours to packagers (like maintainers of RPM or DEB packages). Also, people may not like 'make install' changing the boot-time behaviour of a machine, and/or may not have permissions to modify the boot-time settings. I would suggest putting in a 'setup-boot' target to do this, and ask people to explicitly invoke that rule to integrate your program into the boot setup. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] When all else fails, read the instructions. -- Cahn's Axiom Our policy is, when in doubt, do the right thing. -- Roy L Ash
Re: System configuration during install
David == Lawrence, David (STEI) [EMAIL PROTECTED] writes: David I did not mean to offend by offering the example, I was only David trying to outline my desire within the terms I understood best. Don't worry, I don't think you offended anybody. David If possible, I would like to support the widest range of David systems possible with the constraint that I don't as yet David understand how they vary. Would you be able to suggest a David reference that I could review about portable configuration David techniques for adding and removing dameons to a system's David initialization process? I doubt there's any such reference :-( David I would think that other developers of system daemons must have David already faced this issue when porting to autotools. Maybe you David could also suggest a project I could inspect that needs to David perform this function? I think most people handle this by writing a document for their project that says once `make install' is done, here is how you can set things up... -- with instructions on a system-by-system basis (or even relatively generic, assuming the user understands his own system). System integrators like Debian or Red Hat then put the appropriate commands into their spec (or whatever) files. Most programs aren't system daemons. Requiring special steps for these is the status quo. That is, I think the state of the art here is fairly primitive. FWIW I think Hari is right when he says that most people would be suprised if `make install' changed the boot-time configuration of their machine. RPM builders would be especially suprised -- they use `make install' while building RPMs. Tom
Re: Automake 1.4h
Lars == Lars J Aas [EMAIL PROTECTED] writes: Tom How could we fix it? I mean, conceptually. First off, let me just say that I was considering a larger problem. I was thinking about how to solve the exponential explosion problem for any random variable whose contents we cared about. But I think you're right in that it is most important for _SOURCES, and fixing it there would certainly help. Lars One thing is to change how the *_OBJECTS variables are set up. Lars For each object that depends on some conditional, autogenerate a Lars unique variable name, and set up assignment to it above the Lars *_OBJECTS variable with only those conditionals that are Lars relevant. Suppose we are looking at `windows.c'. Doesn't computing the conditions under which windows.c is built require us to look at every value hello_SOURCES can take? Thus hitting the exponential? However, I think we might be able to do it by looking at variables and not objects or conditions. In fact I think that is what your first example (the one you said was wrong) did: Lars if COND_WINDOWS Lars GUISOURCE = windows.c windows.h Lars else Lars GUISOURCE = gtk.c gtk.h Lars fi Lars bin_PROGRAMS = hello Lars hello_SOURCES = \ Lars $(GUISOURCE) \ Lars algorithm.c \ Lars algorithm.h Lars @COND_WINDOWS_TRUE@automake_obj1 = windows.lo Lars @COND_WINDOWS_FALSE@automake_obj1 = gtk.lo Here automake_obj1 is the renamed GUISOURCE. Now suppose GUISOURCE is defined in a more complex way: if BAR extra = extra.c endif if COND_WINDOWS GUISOURCE = $(extra) windows.c windows.h else GUISOURCE = gtk.c gtk.h $(extra) endif Then we generate: @COND_BAR_TRUE@automake_obj2 = extra.o @COND_BAR_FALSE@automake_obj2 = @COND_WINDOWS_TRUE@automake_obj1 = $(automake_obj2) windows.lo @COND_WINDOWS_FALSE@automake_obj1 = gtk.lo $(automake_obj2) The idea here is that we only have to transform each variable containing sources a single time (per program or library -- we have to name objects different if there are per-exe flags in effect). So the behavior will never be exponential. Right now I don't see any problem with this approach. We do need to traverse all the objects for a given program, because we need to know the type of each one to determine the correct linker. But we can still compute that with the above. Unfortunately, looking at handle_single_transform_list and handle_source_transform, I think this is going to be a fairly major piece of surgery. These functions aren't very well factored, at least not in terms of the modification at hand. Comments? Tom
RE: System configuration during install
Tom, Thanks for the comments. I believe I understand your and Raja's comment related to boot-time configuration: just don't do that ;-). You bring up another point that I was working towards. My intention was to wrap up the autotools project in an RPM for the end-user's use. It appears that with the use of the -rpath argument required by libtool for shared libraries that to build the project I need to have it install the binaries before I can create a binary or source RPM. This does change my configuration where I already have an older version of the software installed. For a typical application, this isn't a problem because it isn't usually running at this point. For a system daemon like mine the probability is high that the daemon is running on my system. I believe a developer should run what they produce. Is there a recommended process for creating RPMs (source and binary) when the files installed replace those that are currently installed on the system? Should I be stopping the current daemon during the pre-install section and restarting it in the post install section? Or leave it unstarted until the user runs the post-install step that changes the system configuration? I am already building using an rpm tree under by home directory. But it would appear that RPM wants me to place the files into their install location before the binary RPM is built. Is this a hard requirement or is there a work-around? If I've moved too far off the context for the automake distribution list, where would you recommend I post these RPM related questions? David G. Lawrence Smart Technology Enablers, Inc. 1121 Rancho Drive Ojai, CA 93023 (805) 649-6660 (805) 649-6667 fax [EMAIL PROTECTED] www.enablers.com -Original Message- From: Tom Tromey [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 05, 2001 8:48 PM To: Lawrence, David (STEI) Cc: 'Raja R Harinath'; '[EMAIL PROTECTED]' Subject: Re: System configuration during install David == Lawrence, David (STEI) [EMAIL PROTECTED] writes: David I did not mean to offend by offering the example, I was only David trying to outline my desire within the terms I understood best. Don't worry, I don't think you offended anybody. David If possible, I would like to support the widest range of David systems possible with the constraint that I don't as yet David understand how they vary. Would you be able to suggest a David reference that I could review about portable configuration David techniques for adding and removing dameons to a system's David initialization process? I doubt there's any such reference :-( David I would think that other developers of system daemons must have David already faced this issue when porting to autotools. Maybe you David could also suggest a project I could inspect that needs to David perform this function? I think most people handle this by writing a document for their project that says once `make install' is done, here is how you can set things up... -- with instructions on a system-by-system basis (or even relatively generic, assuming the user understands his own system). System integrators like Debian or Red Hat then put the appropriate commands into their spec (or whatever) files. Most programs aren't system daemons. Requiring special steps for these is the status quo. That is, I think the state of the art here is fairly primitive. FWIW I think Hari is right when he says that most people would be suprised if `make install' changed the boot-time configuration of their machine. RPM builders would be especially suprised -- they use `make install' while building RPMs. Tom
Re: System configuration during install
David == Lawrence, David (STEI) [EMAIL PROTECTED] writes: David I am already building using an rpm tree under by home David directory. But it would appear that RPM wants me to place the David files into their install location before the binary RPM is David built. Is this a hard requirement or is there a work-around? I haven't made many RPMs. I thought all this stuff worked by installing into a clean tree, say via DESTDIR, and then packaging that new tree. David If I've moved too far off the context for the automake David distribution list, where would you recommend I post these RPM David related questions? I imagine there is an RPM list somewhere. Or maybe someone else here definitely knows the answer. Tom
