Re: Broken install-data-yes target

[Kip Warner]

On Fri, 2013-06-07 at 10:04 -0400, Nick Bowler wrote:
> NB: Spaces are painful because make, for the most part, is impossible to
> use with filenames containing spaces.  

Agreed. When I said it was an issue with Automake, I meant everything
under it inclusive. The real problem is probably in Make.

> 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.

Agreed.

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

Yes. I believe the gettextize tool generates it.

> 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?

Sometimes I configure it with a prefix, other times not. I only
configure it with a prefix if I want to test installing it somewhere.

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

Ok, fair enough. I had tried with the quotations, but keep in mind that
if I add them in the final generated Makefile, it gets overwritten
anyways when the substitutions are made from its input Makefile
(e.g. .am, .in, etc.). So if the path is being fed in via --prefix=...,
then I'm not sure what to do in the future.

> 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,

Thanks Nick. That was helpful. Perhaps when I have time I'll run this by
the appropriate gettext mailing list.

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com

signature.asc
Description: This is a digitally signed message part