Francesco Montorsi wrote: > yes, it's improving - Vaclav tried to make bakefile part of SoC but it > wasn't accepted as mentoring organization. Nonetheless we're talking > about the creation of an instable branch where I'd have write access ;)
Right bakefile needs a bigger group behind it. The problem is typically with IDEs. It's not easy to > give to encode inside their project files the pre-compilation and > post-compilation steps. Right, i think that is the main reason i think that cmake is run as a sort of "configure"script on all platforms. It allows you to do at lease a pre-compilation like thing in Cmake itself. But somehow people think that a configure srcipt on Unix is just fine, but on windows it is not allowed. I mean even bakefile could decide to have some sort of configure step on windows. > Cmake AFAIR is not object-oriented. Bakefile is. And as you know C++ can > be more powerful than plain C... Cmake is written in C++, so i think you mean XML is object oriented?? I miss to see this OO, for me both or about targets and would you do with them. > are there still conflicts in wxLua between different builds? > If there are, please report them in wxlua mailing list. sure. > > >> How often did i need to delete my wxLua checkout, and check it out complete >> again, just to make it compile. >> Else there are left overs after clean, which makes it impossible to compile. >> Cleaning up things properly seems to be difficult. > a "make clean" removes all stuff which has been compiled, I've never had > a problem with that. I do a new checkout now and then, and compile again. And things went wrong several time in the past. And that after telling John it did not compile, with weird errors. And a clean did not help. Only a new/clean checkout did work in those cases. (maybe *.pch files cause the problem, i am not sure. ). > You can post me a list of files which are _not_ cleaned by "make clean" > however. Next time i have it, i will start a search. Its not a known recipe for trouble yet :-) > I proposed to recode wxCode website to be entirely based on those > package descriptors (which would allow faster rendering of the wxCode > pages, automated releases, etc, among other things). But I got no reply > to that mail. Maybe because it was a very very long mail (and we are all > bored by all that text :)). I'll retry shortly. I read it, but i think every one is just to busy to do it. Maybe a tutorial, and not an email. Email pass by and are easily missed/lost. Making twiki pages, is more permanent. But i must be carefully, because it might be there already :-) I am planning to use TWiki for wxArt2D, which is very advanced. >> People are using wxArt2D in Cmake mode, for there own project. They would >> need to switch too, if they want to stay >> platform independent, or at least something like a wxart2d-config would be >> needed. > I don't think that if bakefile replaced cmake in wxArt2d, then those > project would be forced to switch, too. Why should they? > Output libraries would get named&installed in the same way... Its not about libraries and headers. Its about generating makefile/project files for their own code. For Cmake i made a template, which makes a small project, which the users can use as a start, and finds wxWidgets (used to build that wxArt2D), find wxArt2D, and all thirdparty stuff. Next to that all settings for options ( the ones that where used ). You can compare it with what we wanted so much from wxWidgest. Or do you really think the users likes to write his makefiles/project files from scratch? >> I wait patiently. > Let's finally remove them. > I have no much free time and dividing my efforts on too many things is > not going to be a Good Thing for my projects. Oke. I understand, we have something working for wxArt2D even if its based on Cmake ;-) And i am able to maintain it myself. We know very well now how we want to organize things in term of library names etc. If we/i ever continue, with bakefile, i must first have enough time to understand it, and maintain it to a certain degree. Tag the whole thing before you do, so we can always find it back. > > At least, the efforts I put in them were not vain. As said above thanks > to them I reached a deeper comprehensions of the build-related problems > and how they scale with big projects. I can say I've been able to make a > good build system for wxLua only thanks to the work prior done on wxArt2D. I fully agree, and many thanks! > I'll start the removal asap (even if with a little sadness). Same for me, but for the moment it is i think the best think to do. Klaas -- Unclassified ------------------------------------------------------------------------- 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
