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> 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. > 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. > 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. > 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 try running that manually in bash or similar. So that explains > the first error. The second error is explained by the fact that this > broken shell command now is not a normal variable assignment: it sets > dir only in the environment of the (non-existent) Lander command, so dir > is empty for the mkdir command, explaining the second error. The third > error does not appear to have come from your snippet. > > Properly quoting your shell commands should fix it up. I totally agree, but like I said, this Makefile is generated by Automake. I can edit it, but it will just be overwritten anyways. > 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? -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com
signature.asc
Description: This is a digitally signed message part
