Re: Broken install-data-yes target

[Kip Warner]

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