Hi, Klaas Holwerda ha scritto: > Hi Francesco, > > Just for the sake of discussion/learning. ok, sure ;)
>> - it does not require anything else the compiler while cmake requires >> "cmake" exec to be installed on the user's side. From that POV, it's >> also faster to use: in fact the end user does not need to use it in any >> way nor even know about its existence. > > I as a developer, need some version of bakefile generator, python. And what i > remember it is slow. well, a regeneration of all wxLua makefiles/IDE project files takes me 15-20 sec, no more. And that only happens rarely... you can also regen selectively the files you need. > Documentation is so so. Without you behind it, i would have stayed far away > from it. :) > I see you talking about configure, AM files, and it seems to me all > complicated. well, honestly not that much after all. It's just a matter of get used to it. > Not for the user, but for me, and as you say, we really prefer to do other > things. > If the maturity level of bakefile in terms of docs, easy of use etc. is > becoming better, it is becoming more interesting > to people having limited time. That's me :-) 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 ;) > But the amount of make files given to the user is not that small, but it is > at least in few locations. > The real draw back of only having make files for the user, is that certain > things become impossible. > Like i generate the binding for wxLua on the fly, while building. you can indeed launch from makefiles other processes, like e.g. wxLua's binding generator. 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. > >> - it provides a "template-target" architecture which basically is OOP >> translated in the "build system tools logic": you create <template>s >> from which you then derive your targets or other templates (just like in >> C++ you can create classes and inherit others from them). > > What is de advantage of that? Cmake is indeed more like a programming script > language. Cmake AFAIR is not object-oriented. Bakefile is. And as you know C++ can be more powerful than plain C... >> - it does not require a CMakeLists.txt file everywhere > > This one, i find not a problem. I see here and there a Makefile.in next to my > CmakeLists.txt. > I could in fact concentrate all Cmake stuff in one location, I didn't know this. I imagined Cmake required a CMakeLists.txt in each folder. My bad, sorry. >> - running bakefile generates a limited set of files of which you know >> where they go and what they contain. CMake IMHO generates a _bunch_ of >> files here and there, everywhere (thus the strong need of out-of-source >> builds!) > > But this outside source builds is great! It is improving with bakefile, but > there were conflict when building release > and debug in wxLua. are there still conflicts in wxLua between different builds? If there are, please report them in wxlua mailing list. > 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 have problems from time to time with incremental builds but that's normal (typically because win32 compilers are dumb and don't take in dep list for the precompiled headers the headers themselves!). In that case I do a "nmake -fmakefile.vc clean" and then everything works. Don't know why you get such problems. You can post me a list of files which are _not_ cleaned by "make clean" however. > Can bakefile build outside already? As far as i remember wxWidgets itself is > able to. bakefile allows you to do what the underlying format is able to do. autoconf can build software out-of-sources and thus you're able to do that using autoconf. Other formats (e.g. win32 compilers) need some more tricky things to allow that (e.g. call "vc_lib" folders where you put static libs and "vc_dll" the folder where you put DLLs etc). But now with the smart wxpresets that shouldn't be a big problem anymore. >> I know the above points are not enough to convince you to drop cmake in >> favour of bakefile but at least I tried :D > > The feeling i would have by dropping Cmake is the same you have by dropping > bakefile from wxArt2D. > It just does not feel good, after spending so much time on it. Very good point. > And i simply have difficulty to handle bakefile. Good point. > > >>> If wxPM and all wxCode stuff is organized this way, or even using Cmake >>> for some, it all has become easy because things >>> are organized. >> I'm trying to update all my wxCode components and put the WXP descriptor >> file to make them valid wxPM packages but unfortunately wxPM seems not >> to have such a great success in wx users. > > But what wxPM packages are available ?? Currently mainly packages for testing purposes: http://wxwpm.sourceforge.net/packages.php 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 think it takes time, for me the great win is still that things in wxCode > start to work ( like for me wxStedit, is > without problems now ). > Although i still had to use WX_DEBUG=0 and not BUILD=release ?? Hopefully this is going to be fixed in next month. >>> Several modules in wxArt2D can be usefull without anything else (docview), >>> but sofar i have not >>> managed to make them really available as seperate packages. I already >>> seperated the samples to be outside of all >>> modules, that was a first step. The next step would be to organize the >>> modules in such a way that they could be used as >>> wxPM packages if wanted. >> right - but as said the packages would then need individual build systems. > > And can there be something on top, to call the lower packages? sure > There or dependencies between them too. > Anyway that is not the discussion now. right. > >>> So Francesco its up to you. >>> >>> If you think it is better to spend your precious time, improving wxCode and >>> wxLua and what not, i am all with you. >>> Only removing all bakefile stuff in wxArt2D hurts a bit, even if the >>> arguments point to that. >> right. Removing the bakefile stuff from wxArt2D after all the time I >> spent on it seems a waste. >> >> I still have to make a definitive decision... I'll let you know asap. > > You can not ask me to throw away all Cmake stuff just like that, and continue > with bakefile. > 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... > But i see a lot of positive things to in using backfile, the most important being that it is fully synchronized with > wxWidgets and wxlua etc. when it comes to compilers, buidl modes and such. yes, but we agreed having two build systems is/will-be a pain. > 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. 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'll start the removal asap (even if with a little sadness). 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
