Re: Spec draft
- From: Abderrahim Kitouni <a kitouni gmail com>
- To: Nagy Thomas <tnagy256 yahoo fr>
- Cc: buildj-list gnome org
- Subject: Re: Spec draft
- Date: Mon, 11 Oct 2010 18:30:09 +0100
في ن، 11-10-2010 عند 16:57 +0100 ، كتب Nagy Thomas:
> --- El lun, 11/10/10, Alberto Ruiz escribió:
> > >> Good point, added
> > >
> > > The targets will certainly have a mandatory name,
> > won't they?
> >
> > Sure, you can't have a target object in yaml if you don't
> > name the
> > property of the targets dictionary, this is implicit.
>
> Ah, this is not clear in the spec. So, targets cannot have spaces in the name then, can they?.
>
> > > 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.
> 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 buildj.py).
As for allowing extensions in Python, 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)
HTH,
Abderrahim
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]