Klaas Holwerda ha scritto:
> Francesco Montorsi wrote:
>
>> shortly a new <python> tag will be added to bakefile. It will make
>> possible to embed directly python code in the .bkl files. Otherwise you
>> can already code function utilities etc in a separed python file (though
>> AFAIK you cannot declare targets from them).
>
> I see, i wonder why this is needed, reading your opinions down here ;-)
it's needed to implement gracefully some things like e.g. <wx-lib> reordering:
many user complain about non-working makefiles because they put the <wx-lib>
tags in wrong order. The <python> tag will allow me to code in wxpresets a
function which automatically sort the required wx libs in the correct order
(putting e.g. "core" before of "base").
>> The real logic behind the XML choice is: the build system should not be
>> a program but rather an elegant description file which describes what
>> should be built and how. Stop. You don't want e.g. iterative loops in
>> build files, nor you should need a lot of conditionals.
>
> The complexity of the bakefiles and cmake files does not come from defining
> some *.cpp/*.h files to form a library,
> its all the detection of external libraries and so on which makes it
> complicated.
you don't write _any_ detection code in .bkl files. You write it in .ac files
for autoconf format, using BASH shell and not XML.
>> It's not weird to me. It's clear. In C++ you'd write:
>>
>> if (FORMAT=='msvc' or FORMAT=='mingw' or FORMAT=='gnu' or
>> FORMAT=='autoconf') {
>> command( cd $(__cmddir) && $(__cmdstr) );
>> }
>>
>> is it so different ?
>
> No of course not, but i meant that such things are better written in python
> right away. I understand that one needs
> some sort of setup/definition, but this here is forcing extra information
> into XML (since it does not have "if" etc. ),
> and use python to parse that string and make sense of it. To me this is
> misuse of XML for a purpose that does not fit.
> XML is a static thing.
> They could have as well taken some pleasant python naming for
> hashes/variables and reach the same clarity without
> problem, and at the same time have all the flexibility of a programming
> language if need to.
> This is what i like so much about the "premake" solution, it just is plain
> lua, with some added functions to make it a
> makefile generator. In principle that is what bakefile and cmake do, but they
> invented new languages to do it.
>
> Here some XSL stuff i wrote for transforming docbook, same story :-) I must
> be old fashioned, not understanding why all
> needs to be XML these days.
>
> <xsl:for-each select="relation">
> <A HREF="#T_{.}" ><xsl:value-of select="."/></A>
> <BR/>
> </xsl:for-each>
>
> But hey nothing that can be done about it, but i hope premake will win
> eventually :-)
I see your POV but I remain convinced that XML can be a good choice to
"describe" the build system (I'd agree on the point that it can degenerate to a
full "program" like for example, with wx bakefiles used for building wx itself:
they are too long/engarbled!!).
Francesco
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wxart2d-users_dev mailing list
Wxart2d-users_dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxart2d-users_dev
