Re: Buildj file(s)

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

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.

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.

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/

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

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?

Thomas