[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Broken install-data-yes target
From: |
Kip Warner |
Subject: |
Re: Broken install-data-yes target |
Date: |
Thu, 06 Jun 2013 17:58:05 -0700 |
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