Re: Buildj file(s)

[Alberto Ruiz <aruiz gnome org>]

2010/10/5 Nagy Thomas <tnagy256 yahoo fr>:
> --- El mar, 5/10/10, Alberto Ruiz escribió:
>> > * Are files going to be listed as arrays or will it be
>> ok to list file on single lines?
>>
>> Single liners can be done with [file1, file2, file3], but I
>> am not too
>> happy about having too many ways to do stuff (as it'll
>> encourage
>> fragmentation of the way people specify things, and
>> therefore make
>> life harder for people who have to write their own parsers
>> for IDEs
>> and what not).
>>
>> My inclination is to support the following scenarios and
>> discourage
>> [...] list notation:
>> /* Single file */
>> input: file1.c
>>
>> /* Yaml lists */
>> input:
>>    - file1.c
>>    - file2.c
>>
>> /* Glob and Ant glob patterns */
>> input: file*.c
>>
>> input: **/*.c
>
> What about several patterns at once and exclusion patterns? For example,
> include: src/*.ui bar/*.c
> exclude: src/foo.ui
>
>> > * Is the following 'foo.c some\ name.c' going to be
>> interpreted as a list of files or as something else?
>>
>> As per YAML, that's not a list. As I mentioned before, I'm
>> generally
>> against having too many ways of doing stuff. So 'foo.c
>> some' will be
>> 'foo.c some'. There are many file systems that support
>> spaces in the
>> file names and therefor spaces should be spaces not
>> separation between
>> lists.
>
> From a technical point of view, there is of course no problem. But it is important to add this to the specification.
>
>> I haven't thought about that yet, so that's up to be
>> decided :-)
>
> I find this really concerning, for this is an ambitious project. You are expecting some collaboration from lots of actors:
> - the users (to use your file format)
> - IDE people (to read and write project files)
> - template creators (to create templates for the IDEs/users)

Sure, however, one step at a time. This is a format definition, and
there are a lot of things that need to happen before we get to the
point where we encourage people to switch to any buildj
implementation.

> These people have different needs, and will ask for different pieces of information, among others:
> 1. usable tools
> 2. lots of examples
> 3. detailed specifications
> 4. a good validator
> 5. a development timeline

> Here are a few questions:
>
> For 1: Waf or the autotools are already fairly usable. The only way to have developers use buildj is to provide them with a really good incentive to switch. A proof of concept in the form of an IDE plugin to build upon (Anjuta, Kdevelop, Eclipse, ...) and a template (a simple autotool project converted to buildj) are really a minimum.

Well, for a lot of people, not having to learn the waf api, or
autotools, is a good reason enough (provided we have good docs and a
good reference implementation for buildj)

> For 2: Are you going to make a usability review? Try mapping the examples from waf/demos to buildj files to avoid bad surprises. I can give a few ideas, but do not expect me to define the file format.

The usability review is me reviewing the format decisions so far (I'm
not too bothered about implementation). My approach is focusing on
common cases for a given audience (gnome/freedesktop app developers).
I will care about other audiences later.

> For 3: Unlike code/API, a file format is very difficult to document and then to change, and i guess you need some time to make yourself an idea. Where is the link for the current new specs? Is there a wiki for commenting or shall we do it on the mailing list? I am expecting to see something in the form of http://maven.apache.org/pom.html or http://ant.apache.org/manual/Types/

Eventually, as I said, I'll post stuff here when I have time to find
them and get them up to date :-)

> For 4: The yaml parser should include some semantik validation to give meaningful error messages:
>  - Check for invalid parameters / typos
>  - Check for missing files/folders
>  - Warn against all unknown keywords or extensions

I'm planning on having an SAX/XPath inspired API for buildj to allow
scriptability and make the format more robust, something like:

@buildj.handler ('/target/*, obj)
def my_handler (id, subtree, tree)
...
@builj.verify ('/target/*/input', (list, str))

> For 5: The objectives should be prioritized, and a schedule should be defined. When is the usability review going to be performed? When do you expect to see the specification frozen? When do you think buildj will be ready to use for projets of the size of eg: Cheese?

For now it would be a bit unrealistic to set any dates. So I don't
think we can answer that. Note that so far, we need to experiment to
get the spec in a decent shape and direction, and that requires time.
Trying to get there too fast would only risk the scalability and the
flexibility of the format. The project is not mature enough and for
now I think we just need to take one step at a time until we find the
confidence point to be able to go out there and provide stuff.

-- 
Un saludo,
Alberto Ruiz