Re: Broken install-data-yes target

[Nick Bowler]

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/)