Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products

[Michael Catanzaro]

Hi,

This is fine from a release team perspective, as we're already set up
to handle CMake modules. Just make sure to update the JHbuild
moduselets and Continuous manifest at the same time you make the
change. There are already examples of how to handle CMake projects
(e.g. WebKitGTK+).

I'm a little surprised at the use of CMake instead of meson, but that's
your choice to make.

Michael
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products

[Michael Biebl]

2016-10-05 14:54 GMT+02:00 Michael Catanzaro :

> I'm a little surprised at the use of CMake instead of meson, but that's
> your choice to make.

As much as I hate autotools and its arcane syntax, it does bring
uniformity and consistency.
Atm I'm counting waf (for some non-core modules), autotools, cmake and
some are discussing to use meson/ninja.

So while I'm not tied to autotools, I would hate to see if every
modules maintainer chooses his/her own build system of choice. This
makes it really cumbersome as downstream/integrator.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products

[Paul Smith]

On Wed, 2016-10-05 at 15:13 +0200, Milan Crha wrote:
> seems to be better than autotools, gives more freedom and easily
> allows the sources to be built much faster than with autotools (it
> builds here in ~1/3 of the time which uses autotools, still using
> "Unix Makefiles"). I know it's caused mostly by not having one giant
> Makefile.am, but this way it's easier (at least for me).

I have nothing really against CMake (we use it at work to excellent
effect as our product builds on GNU/Linux, OS X, and Windows).  Since I
don't build Evo myself anymore, it doesn't impact me anyway and
developers should definitely do what makes their lives simpler and more
productive.

I will point out that (a) I've had a lot of problems using CMake in a
cross-compilation environment, where autotools works flawlessly and
painlessly (at least as much as is possible when cross-compiling) and
also (b) autoconf's support for command line options that select
different features, etc. is IMO much simpler to work with and use than
CMake's.

But, maybe those things are not so important for Evolution since it's
probably not often cross-compiled and it relies on the GNOME
infrastructure and so maybe has fewer configuration options available.

Cheers!
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products

[Milan Crha]

On Wed, 2016-10-05 at 12:28 +0100, Philip Withnall wrote:
> Out of interest, why?

Hi,
seems to be better than autotools, gives more freedom and easily allows
the sources to be built much faster than with autotools (it builds here
in ~1/3 of the time which uses autotools, still using "Unix
Makefiles"). I know it's caused mostly by not having one giant
Makefile.am, but this way it's easier (at least for me).

With the "gives more freedom" I think of different generators, which
CMake offers quite many [1].
Bye,
Milan

[1] https://cmake.org/cmake/help/v3.6/manual/cmake-generators.7.html
Note it's for version 3.6, while the required CMake version is 3.0
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products

[Bastien Nocera]

On Wed, 2016-10-05 at 09:33 +0200, Milan Crha wrote:
>   Hello,
> this is a heads up that the evolution-data-server, evolution,
> evolution-ews and evolution-mapi products will switch from Autotools
> to
> CMake for the 3.23.1 release.

The email doesn't explain the most important part though. Why? Is it
faster, smaller, or better in other ways? Were other alternatives
considered (Meson,seems to be the preferred non-autotools build system
for GNOME projects)?

Cheers
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products

[Philip Withnall]

On Wed, 2016-10-05 at 09:33 +0200, Milan Crha wrote:
>   Hello,
> this is a heads up that the evolution-data-server, evolution,
> evolution-ews and evolution-mapi products will switch from Autotools to
> CMake for the 3.23.1 release.

Out of interest, why?

Philip

signature.asc
Description: This is a digitally signed message part
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Switching from Autotools to CMake for core evolution products

[Milan Crha]

Hello,
this is a heads up that the evolution-data-server, evolution,
evolution-ews and evolution-mapi products will switch from Autotools to
CMake for the 3.23.1 release. Each of them has created a wip/cmake
branch, which builds and even runs. I tried to keep things as close as
they were with the Autotools, but I made some cleanup changes here and
there (the evolution installs more shared libraries, evolution-ews and
evolution-mapi have some installed libraries renamed and/or added;
header and pkg-config files for the evolution-ews and evolution-mapi
are not provided any more), thus some tweaks in packaging (apart of
calling CMake instead of autotools) will be required.

The build with CMake is straightforward, if you already got in touch
with it. Similar to Autotools, if some feature is enabled and its
dependency cannot be found, then an error is printed with a notice how
to disable the feature if needed. At the end of the configuration phase
are printed all the available options which can be used to tweak the
builds, to both know with what options the project had been configured
and to know what options are available in general.

I plan to merge the changes the next Monday, October 10th, some time
after the 3.22.1 release. This way there will be enough time to catch
any issues before the 3.23.1 release.

I also plan to clean up the source tree a bit, like adding src/
directory into the evolution-data-server and evolution, but I do not
expect it would have any impact on the installed bits. Any custom
distribution patches would need update, of course. I may do some other
miscellaneous changes here and there before and after the merge as
needed.

You can give a try to it already with a snapshot of the wip/cmake
branches [1], if you'd like to. I'd prefer to hear about any issues on
the evolution-hackers@gnome.org list only (I'm not subscribed on the
distributor-list, but on the other two lists I am).

Thanks and bye,
Milan

[1] 
https://git.gnome.org/browse/evolution-data-server/snapshot/evolution-data-server-wip/cmake.tar.xz
https://git.gnome.org/browse/evolution/snapshot/evolution-wip/cmake.tar.xz

https://git.gnome.org/browse/evolution-ews/snapshot/evolution-ews-wip/cmake.tar.xz

https://git.gnome.org/browse/evolution-mapi/snapshot/evolution-mapi-wip/cmake.tar.xz

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers