A CMake build system for wxWidgets

[Thibault Genessay]

Hi all,

I've been using wxWidgets for quite a while now (10 years, OMG) and unfortunately my contributions to the project were pretty small until now - except for a couple of bug fixes. This is unfair for a wonderful project that powers 100% of the desktop applications I ship to my customers. Also, I know most of the maintainers are pretty busy with GSoS projects these days, and I apologize if the moment is less than ideal. Anyway, I have cooked something, and I feel I need some feedback before I can move on.

[rationale/rant]
CMake has gained quite a lot of popularity for good reasons: it works on most platforms, supports most compilers, it is fully featured out of the box and easy to extend. Other project generation tools (including autoconf et al., Bakefile, etc.) serve their own purpose (and do it well), but IMHO CMake is just better. wxWidgets suffers from its versatility: it works on so many OS/compiler/toolkits that maintaining a functional build system takes quite a lot of time. In the meantime, compilers/platforms continue to evolve. The development of Bakefile has halted. Autoconf only works on POSIX systems, etc. CMake elegantly solves many problems with these tools (indeed, it is inspired by them), is actively maintained and has a growing user base. I am not claiming we should use CMake because it's hype. I use CMake for all of my projects, because once you are used to it, there is no way back. No more playing with the horrible VS "project properties" dialog (let's try to change a letter in the output file, for x86/x64/debug/release/dll/static), no more Makefiles, no need to know Ninja/Borland/CodeBlocks to use them.
[/rationale/rant]

Now that you are convinced that CMake is the only hope for truly cross-platform projects :), you will be pleased to hear that I have implemented a proof of concept. It has taken quite a lot of time to understand the current build system, but I came up with something that at least works on several platforms/ports. There are many, many things to improve, but it is a first step. I have tested it on as many platforms as I could get a hand onto:
- Windows 7/MSVC 2013/x64/wxMSW
- Windows 7/Cygwin/x86/wxGTK
- Windows 7/MinGW/x86/wxMSW
- Debian 7(wheezy)/GCC/x64/wxGTK
- OSX (but it does not work, my wife is screaming because she now has an XCode icon in her dock, and I'm no Mac expert at all)

Sure, there have been similar initiatives in the past (a web search reveals a number of forks in Github), but these seem to be limited to project-specific needs (or platform-specific, a counter-use of CMake). A build system should work for everything, everywhere.

My objective today is to get your feeback, so as to know if I should continue working on this toy project, or if I should simply dump it. Questions such as "can it be the official build system one day", "is feature X available on platform Y, compiler Z" are of course far too premature. Although any help would be appreciated, the only answer I need today is: *do you support the idea* ? If I get enough "yes" then I will work towards a beta version that could eventually be integrated side-by-side with the current build system.

I will be also very happy to discuss the architecture of the system (which is quite clumsy for the moment, especially because of assumptions I made about the current build system I was discovering bit by bit) - but let's keep that for another moment.

Finally, here is the Github link:
https://github.com/tibogens/wxWidgets-cmake-build

Thoughts ?

Cheers,
Thibault

[Carsten Fuchs]

Hi Thibault,

my situation is similar to yours: a long time and very happy wxWidgets user with way too
little given back, certainly much less than I myself wish for.

I too had the desire for a build-alternative to Bakefiles in the past; in my case in
order to be able to build wxWidgets from source code along with my application. My
personal favorite build system is SCons, which I prefer over CMake due to SCons' very
simple and clear description of builds, using the Python programming language, and
because it calls the compilers, linkers and other tools directly, no intermediate
project files and whatever generated.

All my other software, including the "external" libraries, is built with SCons, wherein
which I treat wxWidgets as a special-case and fall back to calling make or nmake to
built it. So I made several attempts over the years to build wxWidgets with SCons, too,
but unfortunately never brought it to a level worthy enough to show it to others. To be
honest, I was also a bit scared that the result would break with each new official
release of wxWidgets anyway, and generally spending so much time with creating good
builds already, I was little motivated to load a new maintenance burden upon myself.

In this spirit, although I still prefer SCons over CMake, I was very happy to read your
message, and I agree that it is very important to be able to build wxWidgets with a tool
such as CMake that wide-spread, well established and comes with many known virtues.

(For my own case, my secret hope was/is that learning how wxWidgets is built with CMake
would help with me building it properly with SCons -- but I'd also be happy to review my
prior practices, (re-)learn and maybe switch to CMake entirely.)

In summary, I think that your approach is very worthwhile, and hope that it finds at lot
of additional support among wx-developers and -users. :-)

Best regards,
Carsten



--
Dipl.-Inf. Carsten Fuchs

Carsten Fuchs Software
Industriegebiet 3, c/o Rofu, 55768 Hoppstädten-Weiersbach, Germany
Internet: http://www.cafu.de | E-Mail: in...@cafu.de

Cafu - the open-source game and graphics engine for multiplayer 3D action

[Eran Ifrah]

Hi Thibault,

I became a CMake fan recently and I was happy to read your email

A quick question though: why did you choose to clone the entire wxWidgets repository for this purpose?

i.e. I would choose a different approach of creating a repository with the directory layout that contains the CMakeLists.txt file so a user could simply download the 'zip' file from

GitHub and extract it on top of his/her existing checkout of wxWidgets

As a side note, I think that CMake is the perfect choice as it supports android NDK and I am guessing it will be easier to create projects which involves NDK and wxWidgets in the future.

Beside, it will eliminate the need to maintain various IDEs (namely VS) project/sln files since CMake can generate them

In short, I think that CMake is the way to go

Cheers,

Eran

--
To unsubscribe, send email to wx-dev+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wx-dev

--

Eran Ifrah
Author of codelite, a cross platform open source C/C++ IDE: http://www.codelite.org

wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org

[Thibault Genessay]

Hi Carsten and Eran,

Glad to hear I'm not alone - well, 2 supporters is not much but that's a start :) Thanks for your responses.

First, about CMake (vs. the rest of the world, esp. SCons): I've had a painful experience with SCons in the past, namely the time it took to compile a project. I was a rookie (it was in 2004 IIRC) but the first impression always leaves traces. The KDE team has interesting points of view on the question, although the size of their project is not comparable to wxWidgets. I think there is something irrational in my love for CMake, but I still have some strong arguments for it.

- For instance, CMake generates native project files, unlike SCons which *is* the build tool (and calls compilers/linkers by itself). Some complain about its syntax, which is clearly less elegant than Python's by orders of magnitude, but in the end it does its job (and I would claim that anyone who calls himself a developer can learn it in 10 minutes*). I think that by reading the CMakeLists files you should be able to follow the logic and see how to make your own SCons scripts work.
- The GUIs to control the build are awesome (compared to e.g. the command-line of ./configure).

- I also have success stories in mind, not counting my own: KDE, which I already talked about, but also OpenSceneGraph, that switched to CMake in a painless and happy process.

What is so neat with CMake is that it is the tool for the job. It has aggregated all past experiences of similar tools, and was designed by sound and smart people. I just feel that it is better than other tools - which is quite not the same as saying other tools are bad.

And finally, if I had to keep a single argument: I have expertise with it.

Second, about the organization. Yes, I forked the entire project. I guess I thought it would be easier for other people to try the build system: just download the zip (or git clone the repo) and you're ready to go. But I did not realize people with their own customizations (and hence their own source tree) would then not be able to plug the system in.

The explanation is actually quite simple: I always have a root CMakeLists.txt in my project, so that I can use add_subdirectory() (which, following its name, cannot be used for a parent/sibling directory). So the root file always need to be there, inside the source tree (and not e.g. in a contrib/ dir). This is an assumption I have never challenged - and that might be completely wrong - because I never had the need. I will check this.

Also, I started putting CMakeLists.txt inside the src/ subdirs, but then I realized that there was no 1-1 mapping between directories and modules (e.g. wxbase, wxcore, etc.) so I created CMakeLists for these inside build/cmake/. I could easily move my additions into that directory, which would mean we would be left with only the root CMakeLists outside build/cmake.

I'll try to clean this up today, so that the build system becomes a drop-in component, and will keep you informed.

Thanks again for your responses,

Cheers
Thibault

(*) I mean, learn the *syntax* in 10 minutes. Not: be proficient with CMake. There is actually something very disturbing at first: the CMake code is executed before the generation of the project files, not at build time. This makes it hard to understand e.g. how CMake handles configurations (Debug, Release). It is a similar problem to that of PHP, which generates an HTML page and then gets out of your way (and it makes juniors sad because they want to "catch a mouse event with PHP" and you have a hard time explaining that it won't be possible, ever).

--
To unsubscribe, send email to wx-dev+un...@googlegroups.com
or visit http://groups.google.com/group/wx-dev

[Dmitriy Baryshnikov]

Hi,

my experiments with cmake can be found here (http://forums.wxwidgets.org/viewtopic.php?f=20&t=35122). There is also my cmake version for 3.0.0 not published yet (in forum 2.9.4). A also ready to help.

Also Brian have done some work: cmake-wxWidgets project on Launchpad: https://launchpad.net/wxwidgets-cmake
Also there is https://github.com/smanders/wxcmake

Best regards,
    Dmitry

13.05.2014 13:35, Thibault Genessay пишет:

[Thibault Genessay]

Hi Dmitry,

Thanks for the links! I had actually found the last two, and took some time to inspect yours. As I said earlier, all of these build systems have unfortunately a narrow scope:

- yours and smanders' seem to support only the wxMSW port (correct me if I'm wrong)

- Brian's focuses on GCC

Further, none of these systems include the samples, and none allow the setting of the wxUSE_XXX options through CMake. These 3 points together make me feel uneasy about them. My point is that we should have a single, unified build process, that works on all platforms. This is the only way we can concentrate the efforts, because if a system does not aim at being universal, there is no hope that it can get enough traction to become a standard.

However, if you have the same objective (that is: supporting all platforms, all ports, all options), I'll be delighted to receive your help - and that of all users who read this. Currently, there are many areas that need improvement:

- wxOSX ports

- library naming / output paths (which I see you have already done in your version)

- support of wx-config

- completion of wxconfigure.cmake to handle all options + their dependencies (e.g. switch off wxUSE_OPTION_B if it depends on wxUSE_OPTION_A, which is off)

- monolithic and minimal builds

- etc.

BTW I've pushed some changes to the github repo. Now everything lives under build/cmake, except for the root CMakeLists.txt. So if you want to test this on your own source tree, you can just grab these 2 items instead of checking out the entire repo. As a side note, I've tested the inclusion of the root file into build/cmake (and it works provided you tweak the paths), but since this is something I have never seen in other projects, I am wondering whether it makes sense (from the CMake design standpoint), and what would the implications be (especially w.r.t. integration in a wider project).

Cheers
Thibault

[Eran Ifrah]

On Wed, May 14, 2014 at 3:07 PM, Thibault Genessay <tibo...@gmail.com> wrote:

Hi Dmitry,

Thanks for the links! I had actually found the last two, and took some time to inspect yours. As I said earlier, all of these build systems have unfortunately a narrow scope:

- yours and smanders' seem to support only the wxMSW port (correct me if I'm wrong)

- Brian's focuses on GCC

Further, none of these systems include the samples, and none allow the setting of the wxUSE_XXX options through CMake. These 3 points together make me feel uneasy about them. My point is that we should have a single, unified build process, that works on all platforms. This is the only way we can concentrate the efforts, because if a system does not aim at being universal, there is no hope that it can get enough traction to become a standard.

However, if you have the same objective (that is: supporting all platforms, all ports, all options), I'll be delighted to receive your help - and that of all users who read this. Currently, there are many areas that need improvement:

- wxOSX ports

- library naming / output paths (which I see you have already done in your version) 

- support of wx-config

​I am puzzled with this one, I thought we are building wx with CMake, can you elaborate on this one?

​

- completion of wxconfigure.cmake to handle all options + their dependencies (e.g. switch off wxUSE_OPTION_B if it depends on wxUSE_OPTION_A, which is off)

- monolithic and minimal builds

​I am not familiar with "minimal builds", do you mean "multi-lib" builds? 

--

[Vadim Zeitlin]

On Tue, 13 May 2014 02:35:26 -0700 (PDT) Thibault Genessay wrote:

TG> Thoughts ?

Hello,

This is a painful question for me. On a personal level I simply hate
CMake. I find its syntax horrible, borderline worse than make itself, which
is quite an achievement. I think it's extremely difficult to use for
anything non trivial and, worse, impossible to debug because the files
generated by it are completely impenetrable. I believe it would be arrogant
from our part to require installing a whole build system just in order to
compile wxWidgets and while I agree that it's not a problem nowadays for
Linux, it's still not completely trivial for other Unices (last thing you
want to do when you are building on some Solaris or HP-UX box is to start
by compiling CMake for it) nor, AFAIK, for OS X.

OTOH I'm pretty aware that CMake is the de facto standard. Again, for me
it's purely the case of "worse is better", but there is no denying CMake
success.

So... basically I don't know. For me the ideal build system should
produce simple, native-like (i.e. similar to what you would create
manually) project and make files and not require installing anything
special for the build and this basically already restricts the choice to
bakefile or premake. But if there is no way to satisfy this requirement,
CMake is probably a less bad choice just because it's so widespread.

Considering the number of people using both wxWidgets and Python I'm
a bit surprised that nobody wants to contribute to bakefile 1.x
development. If we could finish it, it would really provide the best of all
worlds. But that's a big "if"...

Regards,
VZ

[Gerald Brandt]

I'm a fan of premake. After trying CMake for a couple of months, I
switched to premake for my projects. It was a dream to use, creates
nice project files, and just works. It took a fews hours to re-create
what had taken over a week to do in CMake.

That being said, I haven't tried it on a project with lots of options
like wxWidgets.

Gerald


--
Gerald Brandt
Majentis Technologies
204-229-6595
g...@majentis.com

[Thibault Genessay]

On Wed, May 14, 2014 at 2:12 PM, Eran Ifrah <eran....@gmail.com> wrote:

- support of wx-config

​I am puzzled with this one, I thought we are building wx with CMake, can you elaborate on this one?

This is for backwards compatibility. While I never use wx-config, users of the library compiled with the CMake system should be able to feel at home and still use wx-config instead of CMake's FindwxWidgets. Actually, wxWidgets being built with CMake has (or rather, should have) no implication on the clients of the library whatsoever.
 

​

- monolithic and minimal builds

​I am not familiar with "minimal builds", do you mean "multi-lib" builds? 

​

I was referring to the --disable-all-features flag of ./configure. The actual "feature" that lies behind this flag is the ability to produce the smallest library for low-end devices. I've never used it, but I think this is typically the kind of option that has to be supported so as to exclude no user from the system.

[Vadim Zeitlin]

On Wed, 14 May 2014 07:26:41 -0500 Gerald Brandt wrote:

GB> That being said, I haven't tried it on a project with lots of options
GB> like wxWidgets.

That's the problem, both premake and bakefile-1 are nice (notice that
bakefile-1 is drastically different from bakefile-0) but are just not
powerful enough. Just to give the first stumbling block I ran into when
thinking about using premake: it doesn't seem to support generating MSVS
projects which contain configurations of the same project building either a
static library or a DLL. FWIW I agree that this is rather unnatural from a
build system view, but we do have this in our current projects and we
don't want to lose the existing functionality.

Also, I'm not sure how good premake support of Xcode projects is in
practice (I do know that CMake is pretty poor BTW). Of course, it can only
be better than bakefile support for them, which is not existent :-(

Regards,
VZ

[Eran Ifrah]

On Wed, May 14, 2014 at 3:26 PM, Thibault Genessay <tibo...@gmail.com> wrote:

On Wed, May 14, 2014 at 2:12 PM, Eran Ifrah <eran....@gmail.com> wrote:

- support of wx-config

​I am puzzled with this one, I thought we are building wx with CMake, can you elaborate on this one?

This is for backwards compatibility. While I never use wx-config, users of the library compiled with the CMake system should be able to feel at home and still use wx-config instead of CMake's FindwxWidgets. Actually, wxWidgets being built with CMake has (or rather, should have) no implication on the clients of the library whatsoever.

The FindwxWidgets.cmake module​ is a wrapper for wx-config under OSX and Linux. It simply executes it and parse the output (strip all -D, -I etc) using regular expressions

and populate the various variables which are used later

 

​

- monolithic and minimal builds

​I am not familiar with "minimal builds", do you mean "multi-lib" builds? 

​

I was referring to the --disable-all-features flag of ./configure. The actual "feature" that lies behind this flag is the ability to produce the smallest library for low-end devices. I've never used it, but I think this is typically the kind of option that has to be supported so as to exclude no user from the system.

​I was not aware of this option, I simply link to 'core' if needed so I avoid the GUI part (this is usually useful when you want to create a wx application with event loop that does not rely on X system)

--
To unsubscribe, send email to wx-dev+un...@googlegroups.com
or visit http://groups.google.com/group/wx-dev

[Thibault Genessay]

Hi Vadim,

On Wed, May 14, 2014 at 2:16 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:

 This is a painful question for me. [...]

As I have put CMake forward with subjective arguments, I cannot blame you for doing the same against it :)

I must admit I am however quite sad to hear your feelings towards this tool are this bad. I know this is a delicate topic, especially for you as you are the maintainer (unless I'm mistaken) of the build system, and the last thing I want to do is hurting your feelings. I have far too much respect for you and your work for that.

I also had not noticed that you and Vaclav were behind Bakefile 1.x, and that I would commit a "crime de lèse majesté" by proposing CMake here.

I just woke up one morning with the desire to help, now you are the one in charge and I am not going against you, whatever that means for this toy project.

Regards,
Thibault

[Vadim Zeitlin]

On Wed, 14 May 2014 15:01:07 +0200 Thibault Genessay wrote:

TG> As I have put CMake forward with subjective arguments, I cannot blame you
TG> for doing the same against it :)

My arguments are partly subjective, true, although I really wonder if
anybody at all actually _likes_ CMake syntax. But there are several
objective ones as well:

- Installing an extra program just to build wxWidgets is a pain and goes
against our "batteries included" philosophy. Ideally you should be able
to download wxWidgets and get up and running immediately and while
compilation is mostly unavoidable (although we now even distribute
binaries to skip this step for some platforms), we really want to make
it as smooth as possible. CMake is an additional program to install and,
worse, an additional layer to have problems with.

- CMake is not nearly as convenient to use with IDEs as hand made projects.
This applies to both MSVS and Xcode.

- Worse, CMake is not as convenient to use as makefiles neither, e.g. you
can't easily do things like "recompile just this file to test my changes".

- Cross-compiling with CMake seems to be painful. I've never tried it
myself to be honest, but this seems nowhere as straightforward and
standard as just specifying the --host=whatever option to configure.

- CMake is less flexible than configure (you can't specify the options as
easily) and, especially with the latest MSVC 10+ projects contributed by
Artur Wieczorek, which are wonderful because they use a separate
properties stylesheet which allows to change build options very easily,
even not as flexible as some IDEs.


TG> I must admit I am however quite sad to hear your feelings towards this tool
TG> are this bad. I know this is a delicate topic, especially for you as you
TG> are the maintainer (unless I'm mistaken) of the build system

De facto, I am. I'd gladly yield this role to somebody else willing to do
it and, in fact, the main appeal of CMake for me is that I hope somebody
else could be doing it instead. But I'm not even sure if it's going to work
in practice.

TG> I also had not noticed that you and Vaclav were behind Bakefile 1.x, and
TG> that I would commit a "crime de lèse majesté" by proposing CMake here.

Bakefile was originally born as an alternative to CMake and I am still
totally convinced that its approach, i.e. generate "native" build files
which can be used just as any hand-crafted projects/makefiles, is far
superior to CMake. And I invite you to compare bakefile (1.x!) and CMake
syntax and tell me what do you prefer.

However, again, in practice, bakefile-1 is just not there yet and it's not
clear who is going to work on it to change it. I'd really like to use this
tool but I'm not (yet) willing to work on it myself.

TG> I just woke up one morning with the desire to help, now you are the one in
TG> charge and I am not going against you, whatever that means for this toy
TG> project.

We do need something better than the current situation where Unix
makefiles and MSVC projects up to 2008 are generated with bakefile-0.x,
Xcode projects are generated by some bespoke AppleScript and MSVC 1[012]
projects are maintained manually (argh). But I don't really think CMake can
help us with this.

Regards,
VZ

[Marcin Wojdyr]

On 14 May 2014 13:31, Vadim Zeitlin <va...@wxwidgets.org> wrote:
>
> That's the problem, both premake and bakefile-1 are nice (notice that
> bakefile-1 is drastically different from bakefile-0) but are just not

I didn't know about bakefile-1. I see it has sphinx documentation.
Is it available on-line? If not, ReadTheDocs is very handy and easy to
configure - you add github hook and RTD generates the latest docs.

I've spent a lot of time during the last 2+ years with cmake and
autotools-based build systems. I have similar feelings.
It's hard to defend the syntax (I'm not sure which is less readable,
cmake or m4sh). Even cmake developers consider the syntax bad.
The command line is even worse, clearly designed to punish people who
don't have caps lock. Seeing -DCMAKE_INSTALL_PREFIX:PATH instead of
--prefix reminds me Interview with an Ex-Microsoftie Who Used to Name
OS Folders.
Yet when I'm asked what to use for new projects I half-heartedly
recommend cmake, because it's mature, well-known and many things work
out of box.
I mean work just well enough. Error-prone syntax makes average cmake
script quite buggy. For example, currently FindQt4.cmake reports wrong
version of qmake like this:
Found unsuitable Qt version "" from NOTFOUND, this code requires Qt 4.x
That's probably not the intended wording (and it would be better to
not fail - it fails on typical Linux installation that has both Qt3
and Qt4, qmake and qmake-qt4), but I can live with it.

If you decide to go with new bakefile or premake I'll learn more about
it. I've been thinking about premake for many months, but I've
postponed investigating it until I have a chance to actually use it.
So I'd be happy to see you move to premake. Or to new bakefile - I
don't know much about this one.

Marcin

[Vadim Zeitlin]

On Wed, 14 May 2014 15:30:12 +0100 Marcin Wojdyr wrote:

MW> I didn't know about bakefile-1. I see it has sphinx documentation.
MW> Is it available on-line?

Unfortunately not yet, although I've been bugging Vaclav to put it
somewhere since a long time. I probably just should do it myself instead...
For now, just have a look at

http://www.zeitlins.org/wx/bakefile/

MW> If not, ReadTheDocs is very handy and easy to configure - you add
MW> github hook and RTD generates the latest docs.

Yes, this is exactly the plan... the only problem is that it hasn't been
done yet.


MW> I've spent a lot of time during the last 2+ years with cmake and
MW> autotools-based build systems. I have similar feelings.
MW> It's hard to defend the syntax (I'm not sure which is less readable,
MW> cmake or m4sh). Even cmake developers consider the syntax bad.
MW> The command line is even worse, clearly designed to punish people who
MW> don't have caps lock. Seeing -DCMAKE_INSTALL_PREFIX:PATH instead of
MW> --prefix reminds me Interview with an Ex-Microsoftie Who Used to Name
MW> OS Folders.

Amen.

MW> Yet when I'm asked what to use for new projects I half-heartedly
MW> recommend cmake, because it's mature, well-known and many things work
MW> out of box.

Again, this is unfortunately my position as well. I can't avoid bringing
up CMake when I'm not able to point to a working alternative. In fact,
bakefile-1 does work fine for Windows and Linux already (even though many
things could be improved). It's the lack of Xcode support which is the
worst problem.

OTOH, again, a couple of my experiences with CMake-generated Xcode
projects made me half wish it didn't support it neither (one of them didn't
build at all, which was at least relatively straightforward to fix, but the
other built _wrongly_ due to some weird settings inheritance mismatch,
which took me an hour to find).

MW> If you decide to go with new bakefile or premake I'll learn more about
MW> it. I've been thinking about premake for many months, but I've
MW> postponed investigating it until I have a chance to actually use it.
MW> So I'd be happy to see you move to premake. Or to new bakefile - I
MW> don't know much about this one.

Both premake and bakefile require some work. For me, personally, it's
easier to work on bakefile written in Python rather than on premake written
(mostly) in Lua. But better still would be to not have to work on it at
all... I'd be glad to help with this work (and I could even pay some money
towards it), but I don't want to officially take on bakefile maintenance.

Regards,
VZ

[Gerald Brandt]

On 2014-05-14, 7:31 AM, Vadim Zeitlin wrote:
> On Wed, 14 May 2014 07:26:41 -0500 Gerald Brandt wrote:
>
> GB> That being said, I haven't tried it on a project with lots of options
> GB> like wxWidgets.
>
> That's the problem, both premake and bakefile-1 are nice (notice that
> bakefile-1 is drastically different from bakefile-0) but are just not
> powerful enough. Just to give the first stumbling block I ran into when
> thinking about using premake: it doesn't seem to support generating MSVS
> projects which contain configurations of the same project building either a
> static library or a DLL. FWIW I agree that this is rather unnatural from a
> build system view, but we do have this in our current projects and we
> don't want to lose the existing functionality.
>

Although I haven't done it, I thought premake4 had the ability to do so.

> Also, I'm not sure how good premake support of Xcode projects is in
> practice (I do know that CMake is pretty poor BTW). Of course, it can only
> be better than bakefile support for them, which is not existent :-(
>
> Regards,
> VZ

[Vadim Zeitlin]

On Wed, 14 May 2014 10:16:46 -0500 Gerald Brandt wrote:

GB> > That's the problem, both premake and bakefile-1 are nice (notice that
GB> > bakefile-1 is drastically different from bakefile-0) but are just not
GB> > powerful enough. Just to give the first stumbling block I ran into when
GB> > thinking about using premake: it doesn't seem to support generating MSVS
GB> > projects which contain configurations of the same project building either a
GB> > static library or a DLL. FWIW I agree that this is rather unnatural from a
GB> > build system view, but we do have this in our current projects and we
GB> > don't want to lose the existing functionality.
GB> >
GB> Although I haven't done it, I thought premake4 had the ability to do so.

How?
VZ

[Gerald Brandt]

My premake4 knowledge is still slim, but I was under the impression you
could use the solutions, projects, and configurations..

I'd have to look into it more to truly answer your question.

[Václav Slavík]

On 14 May 2014, at 16:42, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> MW> If not, ReadTheDocs is very handy and easy to configure - you add
> MW> github hook and RTD generates the latest docs.
>
> Yes, this is exactly the plan... the only problem is that it hasn't been
> done yet.

Not quite. The "only" problem is that RTD won't let you run arbitrary scripts (of course they won't!) and bkl's docs are partially generated… with code that depends on a parser generated by ANTLR (a Java tool). I need to make bkl into a distutils-friendly Python package, make the docs generator independent on the parser and replace the docs-generating makefile with a Sphinx extension; then pray a bit and hope that the changes will be sufficient to make RTD work.

Vaclav

[AZ]

http://industriousone.com/solutions-and-projects ?
FWIW me and another person, jgmdev, started some (unfinished) work to make wx to be built with premake at https://github.com/redtide/wxWidgets/tree/premake some time ago, and we knew about the premake features.
I don't see how someone should say that it doesn't support projects and configurations, the documentation on their website is quite good to see it.

[Vadim Zeitlin]

On Wed, 14 May 2014 18:01:59 +0200 AZ wrote:

A> I don't see how someone should say that it doesn't support projects and
A> configurations, the documentation on their website is quite good to see it.

I'm afraid you didn't read what I wrote carefully enough. I didn't find a
way to create a project like the one we have now, with multiple
configurations building either static library or a DLL, which is quite
different from saying that I didn't find a way to support projects and
configurations.

Regards,
VZ

[Vadim Zeitlin]

On Wed, 14 May 2014 17:41:02 +0200 Václav Slavík wrote:

VS> On 14 May 2014, at 16:42, Vadim Zeitlin <va...@wxwidgets.org> wrote:
VS> > MW> If not, ReadTheDocs is very handy and easy to configure - you add
VS> > MW> github hook and RTD generates the latest docs.
VS> >
VS> > Yes, this is exactly the plan... the only problem is that it hasn't been
VS> > done yet.
VS>
VS> Not quite. The "only" problem is that RTD won't let you run arbitrary
VS> scripts (of course they won't!) and bkl's docs are partially
VS> generated... with code that depends on a parser generated by ANTLR (a
VS> Java tool). I need to make bkl into a distutils-friendly Python
VS> package, make the docs generator independent on the parser and replace
VS> the docs-generating makefile with a Sphinx extension; then pray a bit
VS> and hope that the changes will be sufficient to make RTD work.

Ah, I'm glad I haven't tried to do it myself now. But is it really worth
the trouble? I'd settle for just updating the generated files locally
(either after each commit or even just once a day) and then pushing them
somewhere. Wouldn't this be much simpler (and hence more likely to be done
soon)?

Thanks,
VZ

[AZ]

Isn't it what is explained at http://industriousone.com/configurations-0 ?
You can also use a main batch file to pass some parameters in the same
way you do with configure/wx-config (like --enable-static), but maybe I
miss something else.

[Vadim Zeitlin]

On Wed, 14 May 2014 19:02:17 +0200 AZ wrote:

A> > way to create a project like the one we have now, with multiple
A> > configurations building either static library or a DLL, which is quite
A> > different from saying that I didn't find a way to support projects and
A> > configurations.
A> >
A> You can also use a main batch file to pass some parameters in the same
A> way you do with configure/wx-config (like --enable-static), but maybe I
A> miss something else.

I stand corrected: apparently you can specify "kind" per configuration and
this would indeed take care of this, sorry for somehow missing it when I
searched for this the last time. The documentation[1] mentions that this is
not supported for Xcode, but maybe this is a limitation of Xcode itself and
not Premake.

Anyhow, I'd totally settle for working premakefile for wxWidgets,
especially if somebody could write it :-/

Regards,
VZ

[1] http://industriousone.com/kind

[AZ]

I was in the way to link it to you.
Anyway the problem is always the same: things like this (create a set of
premake build projects for wx that works correctly for all platforms and
all possible configurations) are not for 1 or 2 people only, expecially
without some collaboration from some experienced wx developer.

The only thing I think is that, if bakefile still works based on xml,
premake should be the better solution.

About the xcode issue IDK, I don't remember which xcode version is
supported by premake4 and neither which one is used now in wx.

[Eran Ifrah]

I think that choosing Premake over CMake is a poor decision.

CMake is far more mature with _tons_ of examples online, very active community ( beside wxWidgets, this is the most active mailing list I am signed to) and countless projects using it

This means that many people will fill comfortable to contribute, fix and support it if needed - because it is a standard (whether we agree on this or not) - can you say this about Premake?

Another BIG advantage for CMake is CPack - you can create a native installer (rpm, deb, nsis, dmg etc) based on your CMake INSTALL targets

without the need to even know how to create such package

​

especially if somebody could write it :-/

 Regards,
VZ

[1] http://industriousone.com/kind

[Vadim Zeitlin]

On Wed, 14 May 2014 20:24:20 +0300 Eran Ifrah wrote:

EI> I think that choosing Premake over CMake is a poor decision.

I've listed some of the objective problems I have with CMake. Marcin
listed a few more subjective -- yet also important -- ones.

EI> CMake is far more mature with tons of examples online, very active
EI> community ( beside wxWidgets, this is the most active mailing list I am
EI> signed to) and countless projects using it

This is true, but this is its only advantage. I risk starting another holy
war here but this is akin to saying that everything should be written in
PHP (10 years ago) or JavaScript now. Surely they are both extremely
popular languages, much more so than C++ for example. For me this doesn't
compensate for their multiple problems however.

EI> This means that many people will fill comfortable to contribute, fix and
EI> support it if needed - because it is a standard (whether we agree on this
EI> or not) - can you say this about Premake?

No, but I seriously doubt that anybody from outside of wxWidgets community
is ever going to contribute to CMake build system for it because it will
definitely be quite complicated and just the knowledge of CMake won't be
enough. Whichever tool we use, we need to be able to maintain the build
system ourselves.

EI> Another BIG advantage for CMake is CPack - you can create a native
EI> installer (rpm, deb, nsis, dmg etc) based on your CMake INSTALL targets
EI> without the need to even know how to create such package

We certainly won't use this. We don't need it for Windows installers (the
simple existing .iss works well, attempt to make MSI was a disaster that
I'm not about to repeat) and we don't build RPMs or DEBs at all and
actually removed the files involved in building them a couple of years ago
because all the distributions package wxWidgets themselves in their own way
anyhow.

Regards,
VZ

[Vadim Zeitlin]

On Wed, 14 May 2014 19:20:48 +0200 AZ wrote:

A> Anyway the problem is always the same: things like this (create a set of
A> premake build projects for wx that works correctly for all platforms and
A> all possible configurations) are not for 1 or 2 people only, expecially
A> without some collaboration from some experienced wx developer.

I'd be willing to help with and maintain premakefiles for wx, but there is
still the initial work to be done. And I haven't actually looked at the
MSVS projects it generates yet, I'd really like them to be flexible enough
to allow for the use of property sheets as this is done now.

A> The only thing I think is that, if bakefile still works based on xml,
A> premake should be the better solution.

No, it doesn't, look at the docs I linked.

A> About the xcode issue IDK, I don't remember which xcode version is
A> supported by premake4 and neither which one is used now in wx.

We clearly need support for Xcode 5 and yes, it was unclear what was the
state of this in Premake. Again, with bakefile this is clear though: there
is none :-(

Regards,
VZ

[Marcin Wojdyr]

On 14 May 2014 16:41, Václav Slavík <vsl...@gmail.com> wrote:

>
> Not quite. The "only" problem is that RTD won't let you run arbitrary scripts (of course they won't!)

It seems that any script can be run, here is proof of concept:
http://bakefile-copy.readthedocs.org/en/latest/

I don't know if Java is installed on the build machines, so I've added
hacks to avoid antlr-generated files:
https://github.com/wojdyr/bakefile/commit/9111b97264d48febdc5fa2e8c09d4e592d915548
Therefore no syntax highlighting.

Marcin

[Thibault Genessay]

It seems that the choice has been made (*). I'm still very willing to discuss with those interested in CMake/wxWidgets. I'll keep the list updated on my progress, if there is some (wxBase on OSX/Cocoa is now OK BTW).

Thanks for the interesting dicussion.

Cheers
Thibault

(*) I can't, I just can't, sorry Vadim. This is amazing. You have a product that works everywhere it has been tried (with a little effort, of course). It has a steep learning curve and everyone including me agrees that the syntax sucks. That's about it. Now you want to use an obscure product that has known no release in 4 years, that doesn't support XCode 4 and 5, nor VS 2012+, nor Ninja, etc. Well, if you prefer intentions (however sound and pure) to realizations (however the result of compromises, as all engineering products that happen to work are), there is not much I can do.

[Alexandru Pana]

I think that choosing Premake over CMake is a poor decision.

CMake is far more mature with _tons_ of examples online, very active community ( beside wxWidgets, this is the most active mailing list I am signed to) and countless projects using it

This means that many people will fill comfortable to contribute, fix and support it if needed - because it is a standard (whether we agree on this or not) - can you say this about Premake?

I remember trying really hard to understand and accept CMake. I tried. More than once. I found all those _tons_ of examples useless, much to particular and trivial. It has a horrible syntax which is hard to read and easy to break.

I've started using Premake a couple of years ago and never looked back. Never needed anything else. Besides generating a very wide range of project files, it gives you the freedom of using a popular scripting language for everything else you might need.

I'm willing to contribute to the Premake build files.

[Eran Ifrah]

On Thu, May 15, 2014 at 11:33 AM, Alexandru Pana <astron...@gmail.com> wrote:

I think that choosing Premake over CMake is a poor decision.

CMake is far more mature with _tons_ of examples online, very active community ( beside wxWidgets, this is the most active mailing list I am signed to) and countless projects using it

This means that many people will fill comfortable to contribute, fix and support it if needed - because it is a standard (whether we agree on this or not) - can you say this about Premake?

I remember trying really hard to understand and accept CMake. I tried. More than once. I found all those _tons_ of examples useless, much to particular and trivial. It has a horrible syntax which is hard to read and easy to break.

Lets agree to disagree here. I don't think that CMake syntax is _that_ horrible or unreadable. It is a language. With its pros and cons, I just happen to see more pros than cons, that's all

But I think that Thibault summarized this thread properly (in his last '*' section)

I've started using Premake a couple of years ago and never looked back. Never needed anything else. Besides generating a very wide range of project files, it gives you the freedom of using a popular scripting language for everything else you might need.

I'm willing to contribute to the Premake build files.

--

To unsubscribe, send email to wx-dev+un...@googlegroups.com
or visit http://groups.google.com/group/wx-dev

[Lauri Nurmi]

On Wed, 14 May 2014, Thibault Genessay wrote:

> - For instance, CMake generates native project files, unlike SCons which *is* the build tool (and calls compilers/linkers
> by itself).

This is not true in general. Makefiles generated by CMake are hardly
native -- those Makefiles just call CMake, and CMake is the build tool.
Generated Makefiles cannot be used without CMake installed.

LN

[Dmitriy Baryshnikov]

Hi Thibault,

The CMake not required any changes for wxWidgets. My solution required only copy one file (CMakeLists.txt) and folder cmake to wxWidgets source tree and I think this is good strategy.
I don't see any problem to update/create my CMake scripts for wxWidgets and ready to participate in this work.
If Vadim not like to see cmake in sources, the files can be put to github. Who need can get them there. 
So, don't discuss, let's work :) As you look for several solutions, you need to decide which should be the base for changes, and create project on github and put it there. Share this link to me and others. As soon as this will done, I'll start fixing the Windows part, and, maybe Linux (Ubuntu) part.

Best regards,
    Dmitry

15.05.2014 11:18, Thibault Genessay пишет:

[Thibault Genessay]

Guys,

Sorry for the lengthy post. The plan is at the end. But first, a few points:

On Thu, May 15, 2014 at 12:21 PM, Dmitriy Baryshnikov <bisho...@gmail.com> wrote:

The CMake not required any changes for wxWidgets. My solution required only copy one file (CMakeLists.txt) and folder cmake to wxWidgets source tree and I think this is good strategy.

The current solution I have implemented does not, either. I have made some cleanup, so that only the root CMakeLists.txt "invades" the source tree, and all the rest sits in build/cmake/

 

I don't see any problem to update/create my CMake scripts for wxWidgets and ready to participate in this work.
If Vadim not like to see cmake in sources, the files can be put to github. Who need can get them there. 

OK, this is done: https://github.com/tibogens/wxWidgets-cmake

Do you have an idea using git so that I can merge this into the wxWidgets tree (.gitignore all of wxWidgets except the CMake-related files ? a special git wizardry trick ?)

 

So, don't discuss, let's work :)

I second that :)
 

As you look for several solutions, you need to decide which should be the base for changes, and create project on github and put it there. Share this link to me and others. As soon as this will done, I'll start fixing the Windows part, and, maybe Linux (Ubuntu) part.

As I said in my first message, I have a proof of concept that is much more complicated (convoluted might be the right word) than yours, because it handles 1) all ports, 2) all platforms and 3) all wxUSE_XXX options through the generation of 'setup.h'. Although I am quite certain things are not optimal, these are capacities we want to keep. So if you agree, I think we should start with my files, and refactor them incrementally.

Further, I have tried to be "pluggable" on the current wxWidgets tree. For instance, the list of files is converted from files.bkl, so that a change in the upstream can be reflected by simply re-running a python script. Also, setup.h templates are created from the various setup.0.h (which are themselves updated by build/update-setup-h) - again, upstream change => python script => new list of options in cmake.

This design introduces complexity, but allows us to remain in sync with the current build system. If that changes to e.g. premake, then we would probably have to change as well.

Regarding this, Vadim, independently of the chosen tool for a common build system, there is a big potential for a fruitful collaboration. Right now the management of options is unclear to me - I have not found some sort of central repository that would keep track of all options, their default values based on the platform/port, and which options are available at which conditions (port, again, but also dependency graph).
There is also a documentation page (docs\doxygen\mainpages\const_wxusedef.h).

And there are the various setup.0.h, setup.h.in that contain both the options and the some documentation.

I was wondering whether it would be possible to somehow re-think this, and make the list of options available to whichever build system we use (er... premake or CMake for instance) and doxygen at the same time, so as to ease their management. It would however take some time to review all of them (are they still in use ? etc.).

This would also open doors for continuous integration tests, whereby combinations of options could be tested more easily by automated tools.

OK, time for action, here is the plan:

- the github repo is available (link above), so anyone can already grab the code and try (I have put the generated files in it as well)

- I'll be off for the rest of the week, so it may be a good occasion for you (Dmitry) to start implementing the naming stuff

 and refactoring anything you need without being afraid of conflicts with my work. What's your github username so I can give you push access ?

- Anyone who is also interested can contact me here to be added to the repo

- I have opened the Wiki on github to create a list of tasks. Pick one, put your name, and start coding :)

Cheers,

Thibault

[Dmitriy Baryshnikov]

Hi Thibault,

Good plan. My user name at github is BishopGIS.

Best regards,
    Dmitry

15.05.2014 17:45, Thibault Genessay пишет:

[Vadim Zeitlin]

On Thu, 15 May 2014 15:45:48 +0200 Thibault Genessay wrote:

TG> Further, I have tried to be "pluggable" on the current wxWidgets tree. For
TG> instance, the list of files is converted from files.bkl, so that a change
TG> in the upstream can be reflected by simply re-running a python script.

This is very nice, I didn't realize you did this, thanks!

TG> Regarding this, Vadim, independently of the chosen tool for a common build
TG> system, there is a big potential for a fruitful collaboration.

I'd only welcome that, of course. And concerning CMake, if we could use to
generate working Xcode projects for wxOSX right now, it would be useful,
whatever I or anybody else thinks about it -- just because we don't have
them at all currently.

TG> Right now the management of options is unclear to me - I have not found
TG> some sort of central repository that would keep track of all options,
TG> their default values based on the platform/port, and which options are
TG> available at which conditions (port, again, but also dependency graph).
TG> There is also a documentation page
TG> (docs\doxygen\mainpages\const_wxusedef.h). And there are the various
TG> setup.0.h, setup.h.in that contain both the options and the some
TG> documentation.

The options shared between the ports are in wx/setup_inc.h and the
(very simple) build/update-setup-h script injects it into various
port-specific setup.h's.

TG> I was wondering whether it would be possible to somehow re-think this, and
TG> make the list of options available to whichever build system we use (er...
TG> premake or CMake for instance) and doxygen at the same time, so as to ease
TG> their management. It would however take some time to review all of them
TG> (are they still in use ? etc.).

I'd welcome this too. It would indeed be much better to have a central
list of options, ideally with their dependencies so that (parts of)
wx/chkconf.h could be generated as well.

Regards,
VZ

[Václav Slavík]

On 14 May 2014, at 18:32, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> Ah, I'm glad I haven't tried to do it myself now. But is it really worth
> the trouble? I'd settle for just updating the generated files locally
> (either after each commit or even just once a day) and then pushing them
> somewhere. Wouldn't this be much simpler

Well, less so accounting for your requests to have multiple versions etc… The docs are now generated on RTD, searchable, and support tags (from now on, not older tags). Turned out to be simple enough: https://github.com/vslavik/bakefile/commit/772cb89ee0ccace46274bbde464f3b3f0f22fd86

It's at http://docs.bakefile.org (or http://bakefile.readthedocs.org until the DNS change fully propagates).

Vaclav

[Marcin Wojdyr]

On 16 May 2014 18:16, Václav Slavík <vsl...@gmail.com> wrote:
>
> Well, less so accounting for your requests to have multiple versions etc... The docs are now generated on RTD, searchable, and support tags (from now on, not older tags). Turned out to be simple enough: https://github.com/vslavik/bakefile/commit/772cb89ee0ccace46274bbde464f3b3f0f22fd86
>

nice, it's a better workaround than mine.

One thing, syntax coloring looks wrong:
http://docs.bakefile.org/en/latest/tutorial.html


Marcin

[Dmitriy Baryshnikov]

Hi All,

Yesterday I tested 64-bit build of wxWidgets CMake under Windows (VS C++
2013 Express). It's works on my configuration. Also the 32-bit build
works too. The XP toolsets are supported.
I tested on trunk, get from github. It's maybe rather old, as I pull it
about 3 weeks ago.
To test the Cmake one can clone
https://github.com/tibogens/wxWidgets-cmake and put the repository
contents to the root of wxWidgets source tree.

I didn't test under Linux, but, it seems to me that Thibault did.

I write out some issues, mostly connected with library naming
conventions and install paths
(https://github.com/tibogens/wxWidgets-cmake/issues). This is subject to
discuss.

The feedback is welcome.

Best regards,
Dmitry

15.05.2014 20:03, Vadim Zeitlin пишет:

[Vadim Zeitlin]

On Tue, 17 Jun 2014 10:36:48 +0400 Dmitriy Baryshnikov wrote:

DB> To test the Cmake one can clone
DB> https://github.com/tibogens/wxWidgets-cmake and put the repository
DB> contents to the root of wxWidgets source tree.
...
DB> The feedback is welcome.

Does https://github.com/tibogens/wxWidgets-cmake/blob/master/build/cmake/files.cmake
correspond to the current files.bkl? If so, it could hopefully be generated
from build/files, so that we could maintain at least the most commonly
changing part of the build automatically for CMake too...

Regards,
VZ

[Dmitriy Baryshnikov]

Hi Vadim,

As Thibault wrote: "For instance, the list of files is converted from
files.bkl, so that a change in the upstream can be reflected by simply
re-running a python script."
Here the link:
https://github.com/tibogens/wxWidgets-cmake/blob/master/build/cmake/conv_bakefile_list.py

So, there is no problem with blk. But, as I wrote, there are some
blocking issues (my opinion #1 and #3). I think I can fix them, but I
need some information.
For #1 - Linux standard paths for lib, include, share, etc. files. For
Windows I proposed the paths in issue
For #3 - the naming conventions for libraries.

Best regards,
Dmitry

17.06.2014 18:43, Vadim Zeitlin пишет:

[Vadim Zeitlin]

On Tue, 17 Jun 2014 21:04:44 +0400 Dmitriy Baryshnikov wrote:

DB> As Thibault wrote: "For instance, the list of files is converted from
DB> files.bkl, so that a change in the upstream can be reflected by simply
DB> re-running a python script."
DB> Here the link:
DB> https://github.com/tibogens/wxWidgets-cmake/blob/master/build/cmake/conv_bakefile_list.py

I saw the script but I was unsure if it was just for the initial
conversion, i.e. if the output was later tweaked by hand, or if it could be
reused. If it's the latter, all the better.

DB> For #1 - Linux standard paths for lib, include, share, etc. files. For
DB> Windows I proposed the paths in issue
DB> For #3 - the naming conventions for libraries.

Well, there is not much to say about #1: the libraries must have the same
names as when using the other build methods, I'm not really sure what the
question is there. #3 seems to be about install target which is something
else entirely, again, I'm not sure what is the question precisely? As for
#4, I definitely think we need to be able to build both 32 and 64 bit
versions...

Regards,
VZ