[bakefile-devel] Re: [wx-dev] Adding CW8 XML bakefile support

Hi,

[CC'ing to bakefile-dev for archival]

Dimitri wrote:
> What's the best approach to take? Use an existing CW XML and
> replace parts by the "scripting code"? 

It depends on the format. It usually turns out there's much more 
scripting code than the rest (see *.empy files in Bakefile). If 
there's lot of cruft (like all the <FILE> sections...) in CW XML 
format, then it's the way to go. OTOH, it's hard(er) to extract data 
about the project in the format you need, so I used different route 
when writing both currently existing project files backend (MSVC++ 
and C++BuilderX projects):

The bakefile part (cbuilderx.bkl and msvc6prj.bkl plus 
msvc_common.bkl) are relatively simple but the output part 
(cbuilderx.py and msvc6prj.py) is much more complicated (it's the 
other way around for _makefiles_ -- all the magic is in makefile*.bkl 
and the output is done using a very simple EmPy template). There are 
two approaches here: 

* MSVC++ projects contain cl.exe's command line (i.e. all configurable 
switches such as debug info y/n are translated into cl.exe's 
arguments and stored in this way in .dsp file and the IDE decodes 
this representation when showing project settings dialog). This has 
two consequences: a) I could reuse parts of logic between msvc 
(makefiles) and msvc6prj (.dsps) backends and b) msvc6prj.py has all 
configurable compiler/linker options in three variables  (__cppflags, 
__ldlibs, __ldflags).

* C++BuilderX stores one flag per XML node, so this approach doesn't 
work and it has to have one variable for every bakefile tag (so 
there's __debug variable that stores whatever was specified using 
<debug-info> tag, __threading for <threading> and so on) and all the 
work is done in cbuilderx.py. (This backend is more complicated 
because it has to support three compilers at once and .cbx format is 
not designed well enough to abstract this, but you can safely ignore 
that.)

Have a look at the files mentioned above, it should help a bit. It's 
possible to extend Bakefile with other output methods in addition to 
Empy templates and Python scripts, but it has to be something that 
can run on all platforms (e.g., not AppleScript).

One more thing to mention is that "phony" targets and "action" targets 
(that have arbitrary commands associated with them) are ignored.

> For example removing all
> generic sources from the project, and replacing it with bakefile
> code which loops through available generic sources.

It's not enough to handle sources, you have to address compiler and  
linker options, multiple targets and multiple configurations as well, 
none of which is hardcoded.

> There was talk of making a Bakefile tutorial explaining how to make
> your own makefiles, would I have any use from this tutorial?

A little, probably, but not much...

> What's a good approach to test a CW XML file generated by bakefile?
> The cycle generate XML->Import XML into CW->Check if it opens and
> is correct involves too many manual operations (though I guess
> AppleScript could help here). I could also compare the generated
> XML to a reference XML, is there a tool which can compare XML
> files? (Ignore whitespace differences et al). Or how was validation
> done with the other back-ends?

I usually compared the generated output to known valid one (e.g. 
existing makefile or project file), either with eyes or diff, and 
tried to load/run it only when it looked correct. I think there are 
some xml diff tools, but I used standard one. Also, I started  with 
sample bakefiles (tests/ directory) and moved to wxWindows only when 
all of them worked.

HTH a bit,
Vaclav

-- 
PGP key: 0x465264C9, available from http://pgp.mit.edu/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD4DBQBABnVXxDYa/UZSZMkRAgDsAJi8vVjDiqQ1XusvjIveQY+O9hE0AKCE17Vi
giYMLaz5zryPLgOcWjTLzQ==
=bXMO
-----END PGP SIGNATURE-----