Klaas Holwerda ha scritto:
>> wxArt2D already has a working cmake build system and AFAIK that will
>> remain in place even if bakefile build system is correctly updated and
>> results perfectly working, right?
>
> I am affraid yes. Unless of course the bakefile way is so much better/easier
> etc.
I don't want to start a flame war bakefile vs cmake (thus I won't reply
to all messages of the thread ;)) but I want to just remember some
things which I consider advantages of bakefile over cmake:
- it provides a build system mostly identic to the wxWidgets build
system. This is a bonus for the users because it means that if they
managed to compile wx, they surely will manage to compile also wxArt2d ;)
- 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.
- 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).
- it does not require a CMakeLists.txt file everywhere
- 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!)
- last but not least: IIRC it supports more formats than cmake does.
I'm on Unix and so I'm not 100% sure but bakefile supports:
autoconf GNU autoconf Makefile.in files
borland Borland C/C++ makefiles
dmars Digital Mars makefiles
dmars_smake Digital Mars makefiles for SMAKE
gnu GNU toolchain makefiles (Unix)
mingw MinGW makefiles (mingw32-make)
msevc4prj MS eMbedded Visual C++ 4 project files
msvc MS Visual C++ nmake makefiles
msvc6prj MS Visual C++ 6.0 project files
msvs2005prj MS Visual Studio 2005 project files
symbian Symbian development files
watcom OpenWatcom makefiles
xcode2 Xcode 2.0 project.pbxproj files (UNFINISHED!)
I know the above points are not enough to convince you to drop cmake in
favour of bakefile but at least I tried :D
>> In general, having two build systems mean much more maintainance work.
>> Is it worth the effort?
>
> It would be a nice test case and an example for me and others i think.
>
> I think you agree that although you/we more or less started with wxArt2D, the
> others (wxLua and wxStedit etc.)
> were maybe even more important.
yes, that's right: the bakefile work I've done on wxArt2D was the
trampoline towards a deeper exploration of the subject and the work I've
done on wxLua was a direct consequence of the wxart2d effort :)
> Just because of the fact that you have solved all this bakefile stuff in a
> standard way, the detection with Cmake became
> very easy.
glad to know that.
> 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.
> So for me it starts to look like bakefile and Cmake can used in a mixed
> configuration of packages without much problem.
hopefully any build system which respects the "standards" we are
defining (in terms of naming etc) will be usable in such environment.
>> The more I think to it, the more I'm convinced wxArt2D should stick
>> either with bakefile or cmake, not both.
>
> I that case i would stick with Cmake, because i think it is more flexible,
> and i don't have the time to understand
> bakefile fully.
ok
>> Thoughts?
>
> If with not to much effort you can make the thing work again with bakefile(
> not that much did change ), it would improve
> the current situation. And i am curious how it would work out after all the
> changes to bakefile :-)
much like wxLua... i.e. a 99.9% perfect build system ;)
> And if bakefile really takes of now with wxCode, it might be possible to
> move/make some modules in wxArt2D in the same
> manner as in wxCode.
well, currently wxArt2d bakefiles are in
wxArt2d\modules\build\bakefiles. Thus there is a single .bkl file for
all modules. If they need to be split, then a separed build system
should be created for each one... (but it could be a very simple .bkl
file just declaring the local target).
>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.
> But i have to agree with your remarks on having two systems, delivering and
> doing almost the same, is a waste of
> maintenance time. And this makefiles/configure already takes far to much
> time, which i prefer to spend on programming.
right. I 100% agree. It already takes away too much time from the real
subject of our efforts.
> 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.
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
