Re: Spec draft

2010/10/11 Nagy Thomas <tnagy256 yahoo fr>:
> --- El lun, 11/10/10, Abderrahim Kitouni escribió:
>> > > > The projects will also require waf tools
>> (support for
>> > > c++, python, ...)?
>> > >
>> > > Nope, the tools and the target types are not
>> following waf
>> > > naming
>> > > convetions, the format will have their own and
>> they will be
>> > > mapped to
>> > > any particular implementation. Eventually this
>> need to be
>> > > added to the
>> > > docs.
>> >
>> > What Waf naming conventions? :-)
>> waf uses c, cxx, cprogram, cstlib, cshlib, cxxshlib,
>> cxxstlib while
>> buildj uses cc, c++, vala, program, sharedlib, staticlib.
> Waf also provides program, shlib, stlib and objects (higher-level wrappers). All these are API (not naming convention) but that's off-topic anyway.
>> > How are you going to add such a mapping to a
>> particular
>> > implementation? Will you allow extensions in Python,
>> or will you force
>> > projects to use the latest buildj version?
>> I do not understand your question. Another buildj
>> implementation could
>> use the same naming as buildj natively, or if it's based on
>> some other
>> system (say cmake, if that makes sense), it would use the
>> same naming
>> convention internally and map to the buildj naming as is
>> done in the
>> reference implementation (see WAF_TOOLS and FEATURES_MAP in
>> As for allowing extensions in Python
> If, for example, a project requires support for an esoteric language or for a new compiler, will that project have to wait for a new buildj version with a new specification? Will it also force everybody to update the buildj specification to build such projects? What should the parser do when an unknown attribute is found? reject as invalid or ignore? What about typos (for example "use" instead of "uses").

I have a few ideas, but yes, I want the format to be extensible on a
per project basis (as long as it doesn't rewrite the spec rules), in
the same way that M4 is. However, there is something I'm not
advocating for, at least not at this point. which is a single
scripting api and language for all implementations.

Each implementation should be extended using the language and platform
used by that particular implementation.

>> I like the idea, but
>> we need to
>> define a clear api (I guess it's something like the *Target
>> objects in
>> buildj, and maybe some additional api for hooks)
> You cannot define a clear API for something completely unknown yet, and parsing a real progamming language is a bad idea anyway. What is the policy? Will you allow or forbid users to subvert the system to achieve what they want?
> Thomas
> _______________________________________________
> buildj-list mailing list
> buildj-list gnome org

Un saludo,
Alberto Ruiz

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]