On 2013-06-06 17:58 -0700, Kip Warner wrote: > On Thu, 2013-06-06 at 10:37 -0400, Nick Bowler wrote: > > Moreover, the link provided below is broken, so we cannot see the whole > > Makefile.am. > > Hey Nick. Sorry about that. Try this: > > <https://bazaar.launchpad.net/~avaneya/avaneya/trunk/view/head:/Extras/VLR/Extractor/Makefile.am>
OK. > In any case, I just removed the paths from the spaces. It was painful, > but probably less so in the long run than keeping them there. I wish > Automake didn't still choke on them. This is probably good in the long run. But I don't think this is actually a problem with Automake... see below. NB: Spaces are painful because make, for the most part, is impossible to use with filenames containing spaces. We can basically handle spaces with install directories only because make _mostly_ retains them when doing variable substitution into the shell (where we *can* properly handle spaces), but even this is still problematic in some cases; e.g. make will eat leading and trailing spaces in variable assignments and will also collapse multiple consecutive spaces into one. > > By using @ to suppress the command invocation you have rendered the > > make output essentially useless, because we cannot see what shell > > command is actually being run by make. I suspect the problem would be > > obvious if you did not use @. I recommend avoiding @ for the most part, > > especially for complex shell commands like the above! > > Sorry if I wasn't clear enough. As I mentioned, this is from the > generated Makefile. It's mainly a creature of Automake. The Makefile.am, > however, is above. Ah, I see now. The rule in question appears to come from the Makefile.in.in under Translations; this file is *not* generated by Automake, but rather comes from gettext (and is hand-written, I believe, by the gettext maintainers). > > I can only guess that you have defined > > > > localedir = Viking Lander Remastered > > I hadn't explicitly defined it to anything, but I believe make is > populating those values when I run it. Still, I think the spaces that > where in the path name were a problem because it works fine now that > I've removed them. Looks like they're coming from configure substitutions. So if you look at the generated Makefile(s) you should see localedir = something-or-other in them. Did you configure this package with ./configure --prefix=$PWD/prefix or something? > > or similar. This will obviously fail in your rule since it lacks > > the necessary quoting for the shell. Without the quoting, the shell > > sees > > > > dir=Viking Lander Remastered/$lang/LC_MESSAGES > > How can you quote the shell variable though if its being initialized > not through a string literal constant, but at make time? You can just put quotes around it, because quotes are assumed to not appear in installation directories. So it should be written as dir="$(localedir)/blah blah blah" Unfortunately we have to make these assumptions because make is kind of stupid. (aside: the Automake manual does not include backslashes in the list of prohibited characters for install directories, but they clearly cannot possibly work, so I wouldn't worry about them, either). > > Also, a little error handling goes a long way: your rule totally > > ignored the (easily detectable!) errors and just happily proceeded > > as if nothing was wrong. The make rule then proceeded to run > > installation commands with garbage arguments, and appears to have > > subsequently attempted to create files directly in /. Keep in mind > > that install rules are often run as the superuser. It's no fun for > > anyone involved when a buggy makefile trashes someone's root > > filesystem... > > Absolutely agree. Is this a problem in my Makefile.am, or a bug in > Automake? I think neither. But they do appear to be problems with the gettext-provided Makefile.in.in. You could try patching it up locally and/or pinging the gettext mailing lists. With local patching you may need to take care when you run autopoint so that it is not overwritten (I'm not overly familiar with these tools myself). Hope that helps, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
