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

[Milan Crha]

On Thu, 2016-10-27 at 18:10 +0100, Sam Thursfield wrote:
> On Thu, Oct 27, 2016 at 3:23 PM, 藍挺瑋  wrote:
> > 於 週三，2016-10-05 於 09:33 +0200，Milan Crha 提到：
> > Can we have a common way to enable GTK-Doc installation in modules
> > using CMake? In modules using Autotools, we have --enable-gtk-doc
> > which is recognized by every module supporting generating
> > documentation with GTK-Doc . However, we have two important modules
> > using CMake, Evolution (including Evolution-Data-Server) and
> > WebKitGTK+, but they require different options to enable GTK-Doc.

Hi,
I agree that the consistency is "good to have". I chose the name to
stay as close to the one from autotools as possible. Similarly with
other offered configure options.

> gtk-doc now ships a CMake module upstream:
> .
> 
> I adapted this from existing code in the Firtree project:
> 
> 
> It would be nice if Evo and WebKitGTK+ could switch to using that. It
> may need some improvements; I used it successfully in a couple of
> projects (proprietary ones, sadly) but I don't know how much use it
> has had elsewhere.

Unfortunately, I do not recall what failed for me when I tried to use
it in the time I've been adding the functionality into the libical.
It's couple months ago, it's likely that the things changed on the
GtkDoc side meanwhile, I really didn't give it a try any time recently.

Similarly to WebKit, I currently do not plan to bump GtkDoc dependency,
but it doesn't mean I'm against it. As I begun above, the consistency
is good to have.
Bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[藍挺瑋]

於 週三，2016-10-05 於 09:33 +0200，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.
> 

Can we have a common way to enable GTK-Doc installation in modules
using CMake? In modules using Autotools, we have --enable-gtk-doc which
is recognized by every module supporting generating documentation with
GTK-Doc . However, we have two important modules using CMake,
Evolution (including Evolution-Data-Server) and WebKitGTK+, but they
require different options to enable GTK-Doc.

Evolution only recognizes -DENABLE_GTK_DOC=ON and WebKitGTK+ only
recognizes -DENABLE_GTKDOC=ON. I think it will be better to have single
way to do it, so users don't have to remember to use different options
when building different modules, and jhbuild users can write single
cmakeargs instead of many module_cmakeargs in jhbuildrc when they want
to install GTK-Doc documentation.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Nicolas Dufresne]

Le lundi 10 octobre 2016 à 22:51 +0900, Tristan Van Berkom a écrit :
> 
> I would caution against using only JHBuild as a metric for Meson's
> maturity. Rather I would recommend starting at the lower end of the
> stack, say try to port glib/GTK+ over to use Meson in a wip branch,
> and
> then see how that withstands a cross compile to arm in a wip branch
> against Yocto poky master.

Glib meson branch can be found here:

https://github.com/centricular/glib

best regards,
Nicolas
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Bastien Nocera]

On Thu, 2016-10-13 at 10:18 -0500, Michael Catanzaro wrote:
> On Thu, 2016-10-13 at 11:53 +0100, Sam Thursfield wrote:
> > Would a GNOME-goal to ensure that every project follows the Build
> > API
> > help
> > here?
> 
> 
> What do the meson developers think about the Build API?
> 
> I think I would not support such a goal. I do not want to add a
> boilerplate fake configure script to my project, nor a fake Makefile
> to
> a project that doesn't use make at all. I want to have fewer build
> system files to worry about, not more.

This "build API" is also what Flatpak expects. It's also baked in a
number of package build systems.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Michael Catanzaro]

On Thu, 2016-10-13 at 11:53 +0100, Sam Thursfield wrote:
> Would a GNOME-goal to ensure that every project follows the Build API
> help
> here?

What do the meson developers think about the Build API?

I think I would not support such a goal. I do not want to add a
boilerplate fake configure script to my project, nor a fake Makefile to
a project that doesn't use make at all. I want to have fewer build
system files to worry about, not more.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Nirbheek Chauhan]

Hello,

On Thu, Oct 13, 2016 at 4:23 PM, Sam Thursfield  wrote:
> I agree with the sentiments above that Meson isn't quite ready for this
> yet. I've tried Meson out for 2 projects (Tracker and Rhythmbox) and in
> both cases there have been several patches needed to Meson, some of
> which are still unfinished.
>
> Many people other people seem to be trying out Meson already, which is
> good, and suggests we don't need to do anything further right now to
> encourage people to try it out.
>

Yes, the GNOME module in Meson has had several improvements merged,
and more in the pipeline. Thanks for your patches!

We've been hard at work to make everything work smoothly for GNOME
projects, and have had a lot of interest; particularly from the Vala
folks. It's quite encouraging! Our goal is to have GNOME and Vala
support working flawlessly out of the box ASAP, and people coming and
telling us what they need has been a great help in that regard.

If you are thinking about trying Meson out and need help, hop on to
#mesonbuild on Freenode and find us. :-)

PS: We'd really like some help in making our documentation more newbie
friendly too.

> There are GStreamer build instructions using Meson at
>  (and /gst-plugins-*/) which
> seem pretty complete and I believe they're already being used to
> cross-compile GStreamer to Windows.
>

Just bunch of small corrections. The GStreamer Meson build files have
been merged upstream (alongside Autotools), so it is recommended that
you get them from there:

https://cgit.freedesktop.org/gstreamer/gstreamer/

+ /gst-plugins-{base,good,bad,ugly}, etc.

We also have a git repo that uses Meson's subproject feature to build
gstreamer + plugins in one tree in one go:
https://github.com/thiblahute/gst-all . This is the recommended way of
building GStreamer with Meson on Linux using the system-install
dependencies.

We have our own "jhbuild/continuous-equivalent" called Cerbero that is
used for building GStreamer in other configurations. The default build
used there is still Autotools. For that, we have a branch
(https://github.com/centricular/cerbero) that can build gstreamer +
plugins on Linux, on native Windows, and can cross-compile to Windows
on Linux.

> For GTK+, there are preliminary build instructions for GTK+ at
> . I guess it would be
> a few days work to make these nearly-complete. So I think Meson is close
> to being able to pass that test already.
>

There's also a Glib repository with Meson build files
(https://github.com/centricular/glib), but just like the GTK+ build
it's not complete yet, and we're working on making it have
feature-parity with the Autotools build and the Visual Studio project
files shipped with the project. It's just a matter of going over the
Autotools build files line by line and checking that everything has
been translated over.

Cheers,

-- 
~Nirbheek Chauhan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Sam Thursfield]

On 05/10/16 15:39, Michael Biebl wrote:
>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.

Would a GNOME-goal to ensure that every project follows the Build API help
here?

I feel that should be tied up with improvements to build-api.git that make it
trivial for CMake and Meson projects to achieve Build API compatibility
provided they follow certain conventions.

On 10/10/16 9:49, Sebastian Geiger (Lanoxx) wrote:
> This would of course mean that we already know meson will be the build
> system of choice and that it fits the needs of all modules. Of course
> individual module maintainers would still be free to make a different
> choice or to stick with autotools but we would at least have something
> to motivate the migration, to track its status across all modules and
> it would be a push to towards some level of consistency. Also we could
> collect some best practices from modules that have already done the
> conversion on a Gnome Goal page.

I agree with the sentiments above that Meson isn't quite ready for this
yet. I've tried Meson out for 2 projects (Tracker and Rhythmbox) and in
both cases there have been several patches needed to Meson, some of
which are still unfinished.

Many people other people seem to be trying out Meson already, which is
good, and suggests we don't need to do anything further right now to
encourage people to try it out.

Later on, I agree as well that we should encourage switching away from
Autotools, and recommend (but not mandate) Meson as its replacement.

Both CMake and Meson are much faster than Autotools (like, 3 second
vs. 30 second reconfigure time); so as developers & system integrators
we get a clear benefit.

When writing build instructions I definitely prefer Meson over CMake,
due to CMake's confusing failure cases[1], huge amount of cruft[2],
the strange preference for manually maintained FindPkg* modules over
upstream pkg-config files, and other things. However, making simple
changes to a CMake build system is pretty intuitive so as long as
someone else went through the initial pain of writing them, it's fine
:-)

1. e.g. https://samthursfield.wordpress.com/2015/11/21/
2. e.g. https://cmake.org/cmake/help/v3.4/manual/cmake-properties.7.html


On 10/10/16 at 2:51PM, Tristan Van Berkom wrote:
> I'm not familiar with Meson myself but have had to go through numerous
> headaches dealing with CMake ported projects which tended to build
> well on the maintainers computer but not on mine, or not withstand to
> a cross compile properly. CMake (and it's userbase) is/are starting to
> be mature and these problems are fewer and further between.

CMake has had decent cross-compile support for a while, you just create
a 'toolchain file'. Here's the toolchain file template used by the
Buildroot build
system for example:
.

Meson's works in pretty much the same way:


The state of the art for cross compilation with Autoconf is also to
manually pass in all the config flags that it can't figure out for
itself, e.g.

  http://www.clfs.org/view/CLFS-3.0.0-SYSTEMD/mips64-64/temp-system/bash.html
  
http://www.clfs.org/view/CLFS-3.0.0-SYSTEMD/mips64-64/temp-system/coreutils.html
  http://www.clfs.org/view/CLFS-3.0.0-SYSTEMD/mips64-64/temp-system/tar.html

> I would caution against using only JHBuild as a metric for Meson's
> maturity. Rather I would recommend starting at the lower end of the
> stack, say try to port glib/GTK+ over to use Meson in a wip branch, and
> then see how that withstands a cross compile to arm in a wip branch
> against Yocto poky master.

Agreed, that seems a good test (although I'd test with Buildroot :-).

There are GStreamer build instructions using Meson at
 (and /gst-plugins-*/) which
seem pretty complete and I believe they're already being used to
cross-compile GStreamer to Windows.

For GTK+, there are preliminary build instructions for GTK+ at
. I guess it would be
a few days work to make these nearly-complete. So I think Meson is close
to being able to pass that test already.

Sam
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Olav Vitters]

On Wed, Oct 05, 2016 at 07:54:02AM -0500, Michael Catanzaro wrote:
> 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+).

Not sure why you say this so easily. GNOME modules at the moment are
really easy to package. CMake is annoying. Having each module choose its
own build system is a step backwards.

There's certain requirement each module has to follow, e.g. versioning
scheme and so on. That's for good reasons and one of the benefits. GNOME
releases loads and loads of modules. Its important that we deviate as
little as possible in what we provide.

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

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Sébastien Wilmet]

On Mon, Oct 10, 2016 at 12:45:50PM -0500, Michael Catanzaro wrote:
> On Mon, 2016-10-10 at 12:57 -0400, Owen Taylor wrote:
> > Can you propose what the necessary change would be to:
> > 
> >  https://people.gnome.org/~walters/build-api/build-api.md
> 
> Well that document is Autotools-specific.

The build API is basically a subset of the GNU Coding Standards:
https://www.gnu.org/prep/standards/html_node/index.html

(see chapter 7 The Release Process)

For downstreams, as Michael Biebl already said, it's much easier if all
modules can be built the same way. GNU has written a standard, but new
build systems don't follow it…

The GNU Coding Standards (GCS) has several decades of experience, the
standards are well established, and we can trust the GNU hackers for
having well conceived them. Those that don't follow them are devoted to
reinvent the wheel: they will be faced sooner or later by the same
problems already solved by the GCS and the Autotools.

--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Adrián Pérez de Castro]

Hello all,

Quoting Simon McVittie (2016-10-10 20:57:01)
> On Mon, 2016-10-10 at 12:45 -0500, Michael Catanzaro wrote:
> > On Mon, 2016-10-10 at 12:57 -0400, Owen Taylor wrote:
> > > Can you propose what the necessary change would be to:
> > > 
> > >  https://people.gnome.org/~walters/build-api/build-api.md
> > 
> > Well that document is Autotools-specific. It would need to be written
> > from scratch for CMake following CMake conventions, and separately
> > again for Meson.
> 
> That is exactly the opposite of the intention of Colin's build-api
> specification. The build-api is specifically written so that it
> *doesn't* require every project to be built with Autotools. If it
> assumed Autotools, it would be a much shorter document, starting with
> "you must use Autotools" :-)
> 
> [...]

This is also my understanding. Also, adapting to the build-api is
trivial or easy enough in most cases. Or just planning for it, as
for example in:

  https://github.com/aperezdc/nss-altfiles/blob/master/configure
  https://github.com/aperezdc/nss-altfiles/blob/master/Makefile

(Only 111 and 75 lines, respectively. Zero autotools — only plain
POSIX sh and GNU Make.)

Cheers,

--
 ☛ Adrián


signature.asc
Description: signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Michael Catanzaro]

On Mon, 2016-10-10 at 12:57 -0400, Owen Taylor wrote:
> I agree about whatever we switch GNOME over to en-masse, but for
> scattered projects, I'm less sure, and I'm particularly less sure
> about
> CMake, where there seems to be a certain lack of uniformity.

Hm yes, that's one of the disadvantages to using CMake, each package
has its own way to decide where to install stuff under the install
prefix. I think all GNOME stuff will be using the GNU directory module,
though, in which case we can rely on -DLIB_INSTALL_DIR to work.
Hopefully we can avoid adding CMake projects to Continuous that don't
respect that variable? The only other variable that Continuous needs to
always set is -DCMAKE_INSTALL_PREFIX, which fortunately is standard for
all CMake projects.

> Can you propose what the necessary change would be to:
> 
>  https://people.gnome.org/~walters/build-api/build-api.md

Well that document is Autotools-specific. It would need to be written
from scratch for CMake following CMake conventions, and separately
again for Meson. None of the document is applicable to CMake or Meson
world. I don't think individual projects should maintain compatibility
glue only needed by Continuous regardless.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Owen Taylor]

On Mon, 2016-10-10 at 11:37 -0500, Michael Catanzaro wrote:
> On Mon, 2016-10-10 at 11:51 -0400, Owen Taylor wrote:
> > To get them building again from HEAD again, what you can do is add
> > a
> > compatibility configure script as described in:
> 
> I don't want to add compatibility configure scripts to GNOME modules
> that switch to CMake or Meson. Continuous should just learn how to
> build such modules properly, like JHBuild does.

I agree about whatever we switch GNOME over to en-masse, but for
scattered projects, I'm less sure, and I'm particularly less sure about
CMake, where there seems to be a certain lack of uniformity.

Can you propose what the necessary change would be to:

 https://people.gnome.org/~walters/build-api/build-api.md

? 

> The compatibility
> configure scripts can live in the Continuous git repository in the
> meantime, for as long as they're needed.

I don't think gnome-continuous should be considered to be some sort
dark corner where things should be shoved that only the "gnome-
continuous maintainers" have to worry about. *All* GNOME maintainers
should consider themselves the maintainers of their module in gnome-
continuous.

- Owen

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Owen Taylor]

On Mon, 2016-10-10 at 18:33 +0200, Milan Crha wrote:
> On Mon, 2016-10-10 at 11:51 -0400, Owen Taylor wrote:
> > Javier has tagged evolution and evolution-data-server to pre-cmake
> > versions in gnome-continuous.
> 
>   Hi,
> I know, I coordinate the change with Javier online. He already gave
> me
> two links as examples, I gave him a stub which can be used in all the
> four projects, only the same/similar arguments as in jhbuild will be
> added. I believe the evolution projects will be untagged by the end
> of
> tomorrow or so (I do not want to set any deadline for Javier, I'm
> happy
> he's helping me with this part).

OK. I don't think it particularly makes any sense to carry patches in
gnome-continuous for GNOME-hosted modules - I would expect that if we
need a stub configure script, it should just be added to the module.

- Owen

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Michael Catanzaro]

On Mon, 2016-10-10 at 11:51 -0400, Owen Taylor wrote:
> To get them building again from HEAD again, what you can do is add a
> compatibility configure script as described in:

I don't want to add compatibility configure scripts to GNOME modules
that switch to CMake or Meson. Continuous should just learn how to
build such modules properly, like JHBuild does. The compatibility
configure scripts can live in the Continuous git repository in the
meantime, for as long as they're needed.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Owen Taylor]

On Mon, 2016-10-10 at 17:06 +0200, Milan Crha wrote:
> On Wed, 2016-10-05 at 09:33 +0200, Milan Crha wrote:
> > 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.
> 
>   Hi,
> this is a notice that the changes had been committed to git master of
> the modules and some after-commit fixes had been done as well
> already.

Hi Milan,

Javier has tagged evolution and evolution-data-server to pre-cmake
versions in gnome-continuous.

To get them building again from HEAD again, what you can do is add a
compatibility configure script as described in:

 https://people.gnome.org/~walters/build-api/build-api.md

There are examples of this for CMAKE in:

 https://git.gnome.org/browse/gnome-continuous/tree/patches/

(Search for cmake... the different patches are somewhat different
depending on what particular variables the project uses.)

It's easy to test locally - just do:

 mkdir _build
 cd _build
 ../configure --prefix=/tmp/blah && make && make install

And see if that works.

- Owen

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Milan Crha]

On Wed, 2016-10-05 at 09:33 +0200, Milan Crha wrote:
> 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.

Hi,
this is a notice that the changes had been committed to git master of
the modules and some after-commit fixes had been done as well already.
Bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Tristan Van Berkom]

On Mon, 2016-10-10 at 08:39 -0500, Michael Catanzaro wrote:
> On Mon, 2016-10-10 at 10:04 +0100, Philip Withnall wrote:
> > 
> > I don’t think we’ve ported enough modules as testbeds yet. Meson is
> > too new
> > to jump into encouraging everyone to port GNOME modules en-masse.
> > 
> > Maybe the goal could be proposed in 6 months once Meson has matured
> > a
> > bit
> > more and more modules have dogfooded it?
> 
> Yeah. I've been looking at Meson recently and it looks really nice,
> but
> right now not much is using it in JHBuild, just GStreamer and, as of
> yesterday, libhttpseverywhere. Let's port a couple more modules and
> give it some months before we decide to recommend it project-wide.
> This
> also gives Meson some more time to mature.

I'm not familiar with Meson myself but have had to go through numerous
headaches dealing with CMake ported projects which tended to build well
on the maintainers computer but not on mine, or not withstand to a
cross compile properly. CMake (and it's userbase) is/are starting to be
mature and these problems are fewer and further between.

I would caution against using only JHBuild as a metric for Meson's
maturity. Rather I would recommend starting at the lower end of the
stack, say try to port glib/GTK+ over to use Meson in a wip branch, and
then see how that withstands a cross compile to arm in a wip branch
against Yocto poky master.

If that works well I would say it's pretty much ready.

Cheers,
    -Tristan

> 
> At any rate, I have experience with working on CMake for WebKitGTK+,
> and my initial impression of meson relative to CMake is highly
> positive.
> 
> Michael
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Michael Catanzaro]

On Mon, 2016-10-10 at 10:04 +0100, Philip Withnall wrote:
> I don’t think we’ve ported enough modules as testbeds yet. Meson is
> too new
> to jump into encouraging everyone to port GNOME modules en-masse.
> 
> Maybe the goal could be proposed in 6 months once Meson has matured a
> bit
> more and more modules have dogfooded it?

Yeah. I've been looking at Meson recently and it looks really nice, but
right now not much is using it in JHBuild, just GStreamer and, as of
yesterday, libhttpseverywhere. Let's port a couple more modules and
give it some months before we decide to recommend it project-wide. This
also gives Meson some more time to mature.

At any rate, I have experience with working on CMake for WebKitGTK+,
and my initial impression of meson relative to CMake is highly
positive.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Milan Crha]

On Mon, 2016-10-10 at 10:49 +0200, Sebastian Geiger (Lanoxx) wrote:
> On 05/10/16 15:39, Michael Biebl wrote:
> > 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.
> 
> Maybe it would make sense to introduce an official Gnome Goal that 
> encourages every module maintainer to switch over to
> meson.

Hi,
I didn't mention it earlier, but I didn't pick CMake out of blue. I've
got inspired by the projects the evolution core products depend on.

Some time ago, I touched WebKitGTK+, which uses CMake. Very recently I
helped to upstream libical-glib GNOME hosted project to libical
upstream, which also uses CMake and as I spent some time learning it
during the libical-glib work it was just a natural choice for me. I did
not want to spend more time on learning yet another build system.

No doubt, the CMake isn't perfect (I miss real post-install
steps/commands there, like to recompile gsettings schemas and icon
caches, for which I have workarounds there), but (otherwise) it works
pretty fine for me.
Bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Philip Withnall]

On Mon, 2016-10-10 at 10:49 +0200, Sebastian Geiger (Lanoxx) wrote:
> On 05/10/16 15:39, Michael Biebl wrote:
> 
> > 
> > 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.
> Maybe it would make sense to introduce an official Gnome Goal that 
> encourages every module maintainer to switch over to
> meson.
> 
> This would of course mean that we already know meson will be the build 
> system of choice and that it fits the
> needs of all modules. Of course individual module maintainers would 
> still be free to make a different choice or to stick with autotools but 
> we would at least have something to motivate the migration, to track its 
> status across all modules and it would be a push to towards some level 
> of consistency. Also we could collect some best practices from modules 
> that have already done the conversion on a Gnome Goal page.

I don’t think we’ve ported enough modules as testbeds yet. Meson is too new
to jump into encouraging everyone to port GNOME modules en-masse.

Maybe the goal could be proposed in 6 months once Meson has matured a bit
more and more modules have dogfooded it?

Philip
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Sebastian Geiger (Lanoxx)]

On 05/10/16 15:39, Michael Biebl wrote:


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.
Maybe it would make sense to introduce an official Gnome Goal that 
encourages every module maintainer to switch over to

meson.

This would of course mean that we already know meson will be the build 
system of choice and that it fits the
needs of all modules. Of course individual module maintainers would 
still be free to make a different choice or to stick with autotools but 
we would at least have something to motivate the migration, to track its 
status across all modules and it would be a push to towards some level 
of consistency. Also we could collect some best practices from modules 
that have already done the conversion on a Gnome Goal page.


Personally I would not mind if we got rid of autotools any time soon.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Milan Crha]

On Wed, 2016-10-05 at 17:29 +0100, Javier Jardón wrote:
> Sure, just ping me (jjardon) or any of the release team members
> 
Hi,
thanks a lot, I'll do that once the changes will be merged in the git
master.
Bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Milan Crha]

Hi,

On Wed, 2016-10-05 at 19:13 +0530, Nirbheek Chauhan wrote:
> Meson supports Ninja, MSVC 2010, MSVC 2015, and XCode. Support for
> make was omitted on purpose.

Ah, nice, I misread the list of available backends. My fault. I'm sorry
for that.

Bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Javier Jardón]

On 5 October 2016 at 14:25, Milan Crha  wrote:
> On Wed, 2016-10-05 at 07:54 -0500, Michael Catanzaro wrote:
>> 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+).
>>
> Hi,
> I never touched any of the two, neither I use any of the two, thus it's
> pretty likely I'd more break than fix. Would there be anyone willing to
> do it properly on the first shot "for me", please?

Sure, just ping me (jjardon) or any of the release team members

Cheers,
Javier Jardón
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 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?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Milan Crha]

On Wed, 2016-10-05 at 07:54 -0500, Michael Catanzaro wrote:
> 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+).
> 
Hi,
I never touched any of the two, neither I use any of the two, thus it's
pretty likely I'd more break than fix. Would there be anyone willing to
do it properly on the first shot "for me", please?
Bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Milan Crha]

On Wed, 2016-10-05 at 13:39 +0200, Bastien Nocera wrote:
> Why? Is it faster, smaller, or better in other ways?

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].

> Were other alternatives considered (Meson,seems to be the preferred
> non-autotools build system for GNOME projects)?

Right, Meson. I do not want to dive into such discussion, Meson simply
didn't fit my needs and preferences. Its syntax is weird to me and if
you compare what Meson offers (ninja and msvc2010) and what CMake
offers [1], then it's just "more freedom" from CMake than from Meson.
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
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 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
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list