Re: pattern rules
* Ralf Hemmecke wrote on Wed, Mar 26, 2008 at 10:49:35AM CET: pattern rules are forbidden by automake, but I have the following problem. They are not forbidden. They are unportable to non-GNU make, and automake may not fully understand them, but other than that, there is no problem (and there shouldn't be a problem with your rules). Really? Then I am doing something wrong. In fact, I don't (currently) care about all the different make versions. "configure" looks for GNU-make and should abort if it doesn't find it. After "configure" I would be free to use some GNU extensions, but how do I tell automake about it. I have now put the rule %.abc: %.xyz cp $< $@ into Makefile.am and started "autoreconf". Not it tells me. Makefile.am:8: `%'-style pattern rules are a GNU make extension autoreconf: automake failed with exit status: 1 What should I do? Is there something wrong with AM_INIT_AUTOMAKE([-Wall -Werror]) ? Ralf
Re: pattern rules
* Ralf Hemmecke wrote on Thu, Mar 27, 2008 at 12:05:34PM CET: > > Makefile.am:8: `%'-style pattern rules are a GNU make extension > autoreconf: automake failed with exit status: 1 > Is there something wrong with > > AM_INIT_AUTOMAKE([-Wall -Werror]) As of Automake 1.10, -Wall includes -Wportability. So use -Wall -Wno-portability -Werror instead. Quoting from NEWS: | - `-Wportability' has finally been turned on by default for `gnu' and |`gnits' strictness. This means, automake will complain about %-rules |or $(GNU Make functions) unless you switch to `foreign' strictness or |use `-Wno-portability'. Cheers, Ralf
Re: pattern rules
On 03/27/2008 01:11 PM, Ralf Wildenhues wrote: * Ralf Hemmecke wrote on Thu, Mar 27, 2008 at 12:05:34PM CET: Makefile.am:8: `%'-style pattern rules are a GNU make extension autoreconf: automake failed with exit status: 1 Is there something wrong with AM_INIT_AUTOMAKE([-Wall -Werror]) As of Automake 1.10, -Wall includes -Wportability. So use -Wall -Wno-portability -Werror instead. Quoting from NEWS: | - `-Wportability' has finally been turned on by default for `gnu' and |`gnits' strictness. This means, automake will complain about %-rules |or $(GNU Make functions) unless you switch to `foreign' strictness or |use `-Wno-portability'. Cheers, Ralf Thank you. But what exactly is -Wno-portability allowing? ---BEGIN quote from http://sources.redhat.com/automake/automake.html#Invoking-Automake -W CATEGORY --warnings=category Output warnings falling in category. category can be one of: ... portability portability issues (e.g., use of make features that are known to be not portable) ---END quote It is not so clear what this relates to. Is it only related to the 'make' program or also some portability issues outside of it? In other words, can I simply say "no-portability" and don't relax strictness in places not related to GNU make features? The "e.g." in the above documentation bothers me. What else would automake *not* complain about if I use "no-portability"? Ralf
Are dependency lists statically defined?
Hi all, Over the last couple of months, I've seen a number of people asking questions "around" the topic of building dependency lists. I say "around" because often the question isn't directly related to a particular file list such as: include_HEADERS = file1.h file2.h ... fileN.h But very often, these lists will contain shell expansions, like this: if ENABLED_ADDED_FUNCTIONALITY_A added_functionality_a = fileX.h fileY.h endif include_HEADERS = file1.h file2.h $(added_functionality_a) ... fileN.h Now, here's my question: I've always been under the impression that such dependency lists MUST be statically defined for the sake of automake. Is this no longer true? Or was it ever true? If it's not true, then what is the recommended method for building more dynamic dependency lists? Thanks, John
Re: pattern rules
* Ralf Hemmecke wrote on Thu, Mar 27, 2008 at 01:31:36PM CET: > > -W CATEGORY > --warnings=category > Output warnings falling in category. category can be one of: > ... > portability > portability issues (e.g., use of make features that are > known to be not portable) > > ---END quote > > It is not so clear what this relates to. Is it only related to the > 'make' program or also some portability issues outside of it? Hmm, the documentation doesn't specify this well. Currently, most issues which are warned about revolve around 'make' issues. But there are also a couple of others: - that you may need AM_PROG_CC_C_O if '-c -o' is used in build rules, - that directory names like 'aux' or 'obj' are not portable. > In other words, can I simply say "no-portability" and don't relax > strictness in places not related to GNU make features? What you can do is use -Wno-portability only for those Makefile.am files for which you need it, by enabling it in those files only: AUTOMAKE_OPTIONS = ... -Wno-portability So there are two items where Automake could be improved here: - document exactly the semantics of which options are applied (when they are passed in more than one place: on the automake command line, in AM_INIT_AUTOMAKE, and in per-file AUTOMAKE_OPTIONS), - document which portability issues are warned about with -Wportability, or possibly even split this into separate categories. Discussions and patches welcome. Cheers, Ralf
Re: install mingwm10.dll
On Wed, Mar 26, 2008 at 03:28:26PM -0400, Bob Rossi wrote: > Hi, > > I want to install mingwm10.dll, since my program requires it. I'm trying > to figure out the best way to do this. The dll lives in /c/mingw/bin. > > Would > bin_DATA=/c/mingw/bin/mingwm10.dll > make the most sense? Any suggestions? Maybe I'm missing something, I just read this, http://sources.redhat.com/automake/automake.html#Uniform and I still don't see the answer. I switched over to linux, and got an example to work like this, bin_SCRIPTS = /usr/lib/libglib-2.0.so Is this a stupid thing to do? Is there a better solution? Thank you very much, Bob Rossi
Re: Are dependency lists statically defined?
Hello John, * John Calcote wrote on Thu, Mar 27, 2008 at 03:03:25PM CET: > > include_HEADERS = file1.h file2.h ... fileN.h > > But very often, these lists will contain shell expansions, like this: > > if ENABLED_ADDED_FUNCTIONALITY_A > added_functionality_a = fileX.h fileY.h > endif > > include_HEADERS = file1.h file2.h $(added_functionality_a) ... fileN.h FWIW, this is not a shell expansion, it's an automake conditional which sets a make variable which is used for setting include_HEADERS. > Now, here's my question: I've always been under the impression that > such dependency lists MUST be statically defined for the sake of > automake. Is this no longer true? Or was it ever true? Unfortunately, the answer is "it depends". It depends on the type of lists whether automake needs to know literal file names, and the type also makes a difference in "how" literal those names have to be. The fact that it depends poses one hidden complexity for Automake users, and changes to lessen that dependency are very welcome. Examples on different types of literal-ness: Assume that 'variable' is some automake-magic variable (like include_HEADERS, foo_SOURCES, etc). # completely literal: variable = foo bar baz # This works always. # completely literal, but (conditional) additions: variable = foo if CONDITION variable += bar endif variable += baz # This works for almost all stuff (but notably not yet for # info_TEXINFOS, that's still a TODO item). # using variable expansions with variables defined here, literally, # the variables containing sub-lists: variable = foo $(helper) baz helper = bar # This should work almost always, too. # using variable expansions with variables defined here, literally, # the variables containing sub-words: variable = foo $(subdir)/bar baz subdir = sub # This fails for example with dependency tracking and *_SOURCES, # because the code that generates the stub .deps/foo.Po files is # really dumb in that it greps the Makefile and thus has no idea # about variable expansion. # using variable expansions with substituted variables: # Here, configure.ac contains AC_SUBST([helper]). variable = foo $(helper) baz # This works often, but not always. In some cases it is possible # to get automake to emit the needed rules with EXTRA_ helpers, for # example see EXTRA_PROGRAMS in 'info Automake Uniform', or by using # different magic variables, for example man1_MANS instead of man_MANS # (with the latter, automake needs to be able to extract the man section # from the name). # using shell expansions: variable = fo* # This is almost always a bad idea, because if $(variable) ends up in # some prerequisite list, it will not do the right thing. # using GNU make-specific expansions: variable = $(wildcard fo*) # This works with lists where automake doesn't have to do much except # know that they exist. However, one should keep in mind that automake # can not parse these expansions. Hope that helps. Cheers, Ralf
Re: install mingwm10.dll
Hi Bob, * Bob Rossi wrote on Thu, Mar 27, 2008 at 06:55:26PM CET: > On Wed, Mar 26, 2008 at 03:28:26PM -0400, Bob Rossi wrote: > > > > I want to install mingwm10.dll, since my program requires it. I'm trying > > to figure out the best way to do this. The dll lives in /c/mingw/bin. > > > > Would > > bin_DATA=/c/mingw/bin/mingwm10.dll > > make the most sense? Any suggestions? > I switched over to linux, and got an example to work like this, > bin_SCRIPTS = /usr/lib/libglib-2.0.so > Is this a stupid thing to do? Erm, yes. Even apart from the fact that such a hard-coded path is pretty unportable. > Is there a better solution? I'm not sure what you want to do. You want make install to copy /c/mingw/bin/mingwm10.dll to /usr/local/bin/mingwm10.dll? Why in the world would you want to do that? And if you really want to copy that file somewhere, why do you not just keep it as part of your distribution tarball? And yes, apart from it looking like a weird thing to try in the first place, here's a bunch more reasons against the above: - on my w32 system, mingwm10.dll lives in another place (in fact, it happens not to, but it easily could), - on my GNU/Linux, the library does not exist, but there is an import library libmingw32.a which I think can be linked against, - *_DATA does not set execute permissions on installed files (I think this is less of a problem for w32 than for unixes, but may still be for cross compilation?), - *_SCRIPTS are installed after *_PROGRAMS are installed (or even concurrently with parallel make), so if a program needs the freshly installed library, that can break, - install-strip won't work on that library. I agree that Automake does not provide a good method, only relying on documented interfaces, which can overcome all these issues. Cheers, Ralf
Re: install mingwm10.dll
On Thu, Mar 27, 2008 at 11:51:31PM +0100, Ralf Wildenhues wrote: > Hi Bob, > > * Bob Rossi wrote on Thu, Mar 27, 2008 at 06:55:26PM CET: > > On Wed, Mar 26, 2008 at 03:28:26PM -0400, Bob Rossi wrote: > > > > > > I want to install mingwm10.dll, since my program requires it. I'm trying > > > to figure out the best way to do this. The dll lives in /c/mingw/bin. > > > > > > Would > > > bin_DATA=/c/mingw/bin/mingwm10.dll > > > make the most sense? Any suggestions? > > > I switched over to linux, and got an example to work like this, > > bin_SCRIPTS = /usr/lib/libglib-2.0.so > > Is this a stupid thing to do? > > Erm, yes. Even apart from the fact that such a hard-coded path is > pretty unportable. > > > Is there a better solution? > > I'm not sure what you want to do. You want > make install > > to copy /c/mingw/bin/mingwm10.dll to /usr/local/bin/mingwm10.dll? I want to copy /c/mingw/bin/mingwm10.dll to my bin dir yes. After I do the make install, I will then use something like NSIS to take the install dir and make some sort of installation package for windows. > Why in the world would you want to do that? And if you really want > to copy that file somewhere, why do you not just keep it as part of > your distribution tarball? The problem is, you can't run a mingw application on windows that does not have mingwm10.dll installed if the mingw application uses threads and exceptions. > And yes, apart from it looking like a weird thing to try in the first > place, here's a bunch more reasons against the above: I hope it doesn't seem wierd now. I have to give the user the mingwm10.dll, so, I think it should be installed. > - on my w32 system, mingwm10.dll lives in another place (in fact, it > happens not to, but it easily could), I know, I don't know what to do about this, besides write a macro to find it, that will come next if needs be. > - on my GNU/Linux, the library does not exist, but there is an import > library libmingw32.a which I think can be linked against, My linux version of this program does not need the library, as I simply use the normal gcc, not the mingw version. Perhaps the version on linux you are looking for is for cross compiling? > - *_DATA does not set execute permissions on installed files (I think > this is less of a problem for w32 than for unixes, but may still be > for cross compilation?), OK, I'm not using data anymore. > - *_SCRIPTS are installed after *_PROGRAMS are installed (or even > concurrently with parallel make), so if a program needs the freshly > installed library, that can break, > - install-strip won't work on that library. > > I agree that Automake does not provide a good method, only relying on > documented interfaces, which can overcome all these issues. Thank you very much for this description, it was really helpful. I'm currently using the bin_SCRIPTS solution. It seems to work for now. Thanks again, Bob Rossi
Re: install mingwm10.dll
* Bob Rossi wrote on Fri, Mar 28, 2008 at 12:47:25AM CET: > > I want to copy /c/mingw/bin/mingwm10.dll to my bin dir yes. After I do > the make install, I will then use something like NSIS to take the > install dir and make some sort of installation package for windows. > > > Why in the world would you want to do that? And if you really want > > to copy that file somewhere, why do you not just keep it as part of > > your distribution tarball? > > The problem is, you can't run a mingw application on windows that > does not have mingwm10.dll installed if the mingw application uses > threads and exceptions. That doesn't explain why you aren't just shipping mingwm10.dll along with you distribution tarball, and copying it from there. > > And yes, apart from it looking like a weird thing to try in the first > > place, here's a bunch more reasons against the above: > > I hope it doesn't seem wierd now. I have to give the user the > mingwm10.dll, so, I think it should be installed. Or simply list a MinGW installation as dependency of your package. > > - on my w32 system, mingwm10.dll lives in another place (in fact, it > > happens not to, but it easily could), > > I know, I don't know what to do about this, besides write a macro to > find it, that will come next if needs be. See above, you could just ship it. > > - on my GNU/Linux, the library does not exist, but there is an import > > library libmingw32.a which I think can be linked against, > > My linux version of this program does not need the library, as I simply > use the normal gcc, not the mingw version. Perhaps the version on linux > you are looking for is for cross compiling? Yes, I meant cross-compiling. Sorry for not stating that up front. Cheers, Ralf
