[webkit-dev] New XML format for .in files

Wed Jun 11 14:55:51 PDT 2008

On Wed, Jun 11, 2008 at 9:54 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Jun 11, 2008, at 1:41 PM, Eric Seidel wrote:
>
>> Julien and I discussed some of these during the patches.  I'm sure
>> he's open to further suggestions.
>>
>> 1.  The idea has been that "long term" xml is easier than a custom
>> parser (He's been slowly moving more of the custom-hacks in the perl
>> script into .in file data).  I agree, the current solution is
>> less-than-ideal to author, and I certainly agree things like
>
> In my experience, that's not really true, if your file format is very imple.

As Eric stated, the format is not fixed. As long as the new format can
hold more that just the names, it is fine.

I am not for a custom format as I do not think we want to write yet
another parser.

I chose xml for 3 reasons:
1) I did not find a good parser in the perl core modules (most our
scripts are in perl so I did not want to switch to another language).
2) we cannot introduce new dependencies so we need a pure perl parser.
3) the choice of pure perl parsers is limited and I found that this
module seemed the best alternative (only one file, quite limited but
we did not need a lot of functionality, fair documentation ...).

I may have missed some opportunities and would happily switch to
something else. The core of the issue is to move some perl hacks that
were in make_names.pl to the files where they should be. The idea was
also to make the automatic generation more extensible (which would be
nice for XBL2 but also for other extension we may have to do).

>> (2.)
>> <tag>href</tag> are even worse.
>> 3.  Julien and I discussed this as well.  I decided it was less than
>> ideal, but not worth worrying about.  Dealing with maintaining the
>> right command line flags in each of the 8 build systems people use
>> seemed more of a pain than this data/logic violation.
>
> The only place that should need to know about the flags is
> DerivedSources.make.

You have forgotten GNUmakefile.am and WebCore.pro. I guess other
unofficial ports also have their custom files.

> And it has to know what files are getting generated
> anyway, to get the dependencies right. Furthermore, the different build
> systems do have to be changed to add the right files, which is probably
> going to be more confusing if what files are generated is implicit in the
> contents of the .in file.

Yes, all the build systems do use the same generated files and would
need to be modified anyway. Some of what was moved were common to all
the platforms (namespace, ...) and did not state which kind of files
were generated. Such attributes could easily be removed from the
command line. Especially since providing one of these parameters
incorrectly would only break one build and would be difficult to find
out.
We could keep the parameters that state what is generated in the
command line (like --wrapperFactory and --factory).

>> I would encourage you to discuss this at greater length with Julien over
>> IRC.
>
> I sent email on purpose because I'd like us to start discussing more
> technical issues like this on the mailing list. Mailing list discussion
> makes it easier for people who aren't on IRC all the time or not in the
> right time zone to follow the technical discussions of the project. But I am
> happy to discuss on IRC as well.

I am fine with both too.

Best regards,

Julien

> Regards,
> Maciej
>
>>
>>
>> -eric
>>
>> On Wed, Jun 11, 2008 at 12:55 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>
>>> Here's what the new format looks like (WebCore/xlinkattrs.in):
>>>
>>> <attrs namespace="XLink" cppNamespace="WebCore"
>>> namespaceURI="http://www.w3.org/1999/xlink
>>> ">
>>> <actuate/>
>>> <arcrole/>
>>> <href/>
>>> <role/>
>>> <show/>
>>> <title/>
>>> <type/>
>>> </attrs>
>>>
>>> I must admit I don't really like this. First, if we need to have this
>>> info in the file, I think it would be simpler to use a simple custom
>>> format with a few key-value entries to start and then the attributes:
>>>
>>> namespace=XLink
>>> cppNamespace=WebCore
>>> namespaceURI=http://www.w3.org/1999/xlink
>>> actuate
>>> arcrole
>>> href
>>> role
>>> show
>>> title
>>> type
>>>
>>> This would still be easier to parse than XML and certainly easier to
>>> author.
>>>
>>> Second, I think this is a poor use of XML - having a new XML tag name
>>> in this .in file for every attribute or element in a namespace means
>>> there's no real defined XML language here, the tag names are
>>> completely ad-hoc, which means this is effectively putting content in
>>> markup, which is not good. The more natural XML-style way would be to
>>> say <attr>actuate</attr> instead of <actuate/>, but of course that
>>> adds more syntactic noise. So again I think the plaintext format is
>>> better.
>>>
>>> And finally, I am not sure I like defining all the parameters to the
>>> generator script inside the file. For example:
>>>
>>> <attrs namespace="SVG" cppNamespace="WebCore"
>>> namespaceURI="http://www.w3.org/2000/svg
>>> " generateFactory="1" generate
>>> WrapperFactory="1" guardFactoryWith="ENABLE(SVG)" nullNamespace="1">
>>>
>>> This is defining what actual implementation files get generated, and
>>> what #ifdef guards to put into them, which seems like too much
>>> implementation detail to put into a file defining attributes. I think
>>> it does make sense to put the namespace URI in, but it doesn't seem
>>> right to include details about the generated files. The .in files
>>> should stick to holding the data, not the implementation details, in
>>> my opinion.
>>>
>>> Comments?
>>>
>>> Regards,
>>> Maciej
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>
>