Re: FYI: escape shell meta-chars in tag variable comments [libtool--release--2.0--patch-10]

[Ralf Wildenhues]

* Bob Friesenhahn wrote on Thu, Oct 07, 2004 at 06:38:01PM CEST:
> On Thu, 7 Oct 2004, Ralf Wildenhues wrote:
> 
> >* Bob Friesenhahn wrote on Thu, Oct 07, 2004 at 04:44:11PM CEST:
> >>>part.  Do we have to do it like this?  Did released versions of Libtool
> >>>also create lines like this (i.e., do we have to support it anyway)?
> >>
> >>The content of .la files has varied over the years and also varies
> >>from system to system.  It seems like you will need to collect a few
> >>thousand existing .la files from many different systems so the code
> >>can be fully tested before it is deployed.
> >
> >I would like to fix the possible syntax, not its semantics (most of
> >that is unnecessary for ltdl anyway).
> 
> I don't see how the syntax of existing .la files can be fixed.  It may 
> take several years before the world is using libtool 2.0 or later.

Again I am sorry for being not precise enough in my language, hence
another misunderstanding.

What I meant by `fix the possible syntax', is: I would like to know the
minimal syntax requirements to which all .la files in use adhere.
Then I want to write that down in some (possibly new) section of
libtool.info.  I do not want to change existing installed files at all.
(`fix' in the sense of determine).

I know of a guaranteed minimum, at least that's what I thought so far:

- They are parseable by a Bourne shell.
- The subset of the file of interest to ltdl consists only of a few
  lines of them which are variable assignments.
- All of the ltdl-interesting variables either do not contain any kind of
  expansion (be that variable expansion, globbing, @foo@ substitution)
  or that expansion is not important for ltdl.

If any of the above points are wrong, I'd be really glad to be
corrected.  Because then either current `libtool' or current `libltdl'
need to be corrected (I am not talking about my proposed changes, but,
branch-1-5 or branch-2-0 make these assumptions, too).

So now the next question would be:
What else can I possibly enforce on all existing .la files?

Why could that question be worthwhile (besides being part of the TODO
list)?  Because external software might eventually want to generate .la
files.  And for that, as a first step, it would need some sort of
description of what's in there.  Syntax would only be the first step in
that direction.

> In summary, what I am saying is that applying the new rules would be 
> difficult to implement in practice and would take substantial time.

I do not want to invest that time.  Rather find out a minimum of
enforceable conventions and document that.

Regards,
Ralf