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

2016-10-31 Thread 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
___
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

2016-10-27 Thread Sam Thursfield 
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.

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.

Sam
___
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

2016-10-27 Thread Emmanuele Bassi 
It would be nice to have gobject-introspection ship a cmake module as well.

I've already had to fix libical and evolution-data-server in
Continuous because of a mismatch between Makefile.introspection and
cmake.

Additionally, if somebody well versed in cmake could help out with
this issue, it would be great:

  https://github.com/libical/libical/pull/246

Ciao,
 Emmanuele.

On 27 October 2016 at 18:10, 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.
>
> 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.
>
> Sam
> ___
> desktop-devel-list mailing list
> desktop-devel-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
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

2016-10-27 Thread 藍挺瑋 
於 週三，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.
___
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

2016-10-10 Thread 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
___
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

2016-10-10 Thread Gilles Dartiguelongue 
Le lundi 10 octobre 2016 à 10:01 +0200, Milan Crha a écrit :
> On Fri, 2016-10-07 at 09:39 +0200, Gilles Dartiguelongue wrote:
> > 
> > Also, does CMake support make distcheck yet ? As a downstream
> > maintainer, I find many packages with errors in distributed sources
> > would have been caught by make distcheck when releasing.
>   Hi,
> CMake doesn't "support" it by default, but I have there custom
> targets
> named "dist", "distcheck" and "disttest", the same as "check". Note
> that the 'dist*' targets create the tarball from a git clone first,
> thus it won't work with the tarball sources. It didn't work well with
> the autotools too, I think, where you better build the sources and
> run
> 'make check' only.

I guess it is too late to talk about this but what problems did
autotools had with make distcheck ? I regularly used it when
contributing patches to evo/eds and still do when preparing patches for
any autotooled package.

-- 
Gilles Dartiguelongue 

___
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

2016-10-10 Thread Simon McVittie 
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" :-)

It *is* designed such that implementing it in Autotools modules is
trivial, because the free software world (with a particular focus on
the parts of it in and below GNOME) already contains a lot of
Autotools. Would you have preferred it to take the form

    ./build-api.sh prepare with_libdir=/usr/lib64
    ./build-api.sh build
    ./build-api.sh install with_root=/foo

(ensuring that in practice, *every* project needs modifications if it
is to implement the build-api) out of some sense of artificial
neutrality?

The intention of the build-api, as I understand it, is to avoid this:

https://git.gnome.org/browse/jhbuild/tree/jhbuild/modtypes

and this:

https://anonscm.debian.org/git/debhelper/debhelper.git/tree/Debian/Debh
elper/Buildsystem

or if you think package-based distributions are a thing of the past[1],
this, part of the base on which gnome-continuous and the reference
Flatpak runtimes are built:

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/recipe
tool/create_buildsys.py

or further away from GNOME, this:

https://quickgit.kde.org/?p=kdesrc-build.git=tree=a6fa7cd83f0fbae52
4a63952c3c3bf607b7566d0=f187eaf9ff7b3994de649377abf18f131fee03ef=m
odules%2Fksb%2FBuildSystem

and more generally, everyone who builds an operating system having to
invent an abstraction layer across popular and semi-popular build
systems to map them into their favourite meta-build system.

(I'm using "operating system" rather loosely here: Flatpak doesn't
build operating systems, as such, but flatpak-builder uses the build-
api to build runtimes and apps.)

    S

[1] I don't

-- 
Simon McVittie, Collabora Ltd. 

___
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

2016-10-10 Thread 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
___
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

2016-10-10 Thread 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
___
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

2016-10-10 Thread 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

___
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

2016-10-10 Thread 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
___
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

2016-10-05 Thread 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

2016-10-05 Thread 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

2016-10-05 Thread 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

2016-10-05 Thread 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

2016-10-05 Thread 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

2016-10-05 Thread 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

2016-10-05 Thread 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