Tom Tromey <[EMAIL PROTECTED]> writes:
> Akim> Patch is several chunks because it took me several steps to
> Akim> reach the right one.
>
> That makes it a lot harder to read. Please don't do that.
I didn't mean it :( It really that I discovered side effects later
on. I should have built a independent automake.in to reconstruct a
cleaner patch, sorry. I will next time.
> Akim> - => $am_var_defs{'_am_installdirs'} || ''));
> Akim> + => $contents{'_am_installdirs'} || ''));
>
> In general code outside the variable manipulation "module" should not
> directly use %contents. I know some code does (the SOURCES/OBJECTS
> stuff), but that code is really, really old and could probably be
> removed.
>
> This code used to use $am_var_defs, but that was wrong too.
I know. I definitely know. That's precisely what I'm doing: cleaning
up the handling of variables. But I try to do it by logical chunks,
so this is just delayed.
> Incidentally do we give an error if the user tries to define
> _am_installdirs? It seems like we should.
Yes, definitely. But first I am factoring everything, then it will be
easy in *one* place to have all the sanity checks we want. I saw you
had that request in TODO, this is fine. But really, I can't do
everything at once :(
> It also seems to me that one problem with the whole _am_installdirs
> idea is that we end up introducing a useless variable. Ideally we'd
> leave useless variables out of Makefile.in.
If this variable is output, I have something wrong somewhere I didn't
notice. To be honest, *because* I wish that there is no magic in *.am
files, my first intention was to have a variable actually output,
originally named INSTALLDIRS, and have mkinstalldirs use this macro.
The current implementation has some magic to *subtitute* INSTALLDIRS
at Automake time, and I wish it doesn't. Since we can do it with more
dignified tool, more regular processing, I would really prefer the
latter choice.
