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

--Boundary-02=_XVnBATJYN42sIHS
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

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"?=20

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

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

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

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

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

One more thing to mention is that "phony" targets and "action" targets=20
(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 =20
linker options, multiple targets and multiple configurations as well,=20
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.=20
existing makefile or project file), either with eyes or diff, and=20
tried to load/run it only when it looked correct. I think there are=20
some xml diff tools, but I used standard one. Also, I started  with=20
sample bakefiles (tests/ directory) and moved to wxWindows only when=20
all of them worked.

HTH a bit,
Vaclav

=2D-=20
PGP key: 0x465264C9, available from http://pgp.mit.edu/



--Boundary-02=_XVnBATJYN42sIHS
Content-Type: application/pgp-signature
Content-Description: signature

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

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

--Boundary-02=_XVnBATJYN42sIHS--