Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products
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
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
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] Heads-up: Evolution-Data-Server and Evolution to depend on WebKit2 since 3.21.90
On Wed, 2016-08-10 at 14:25 +0200, Milan Crha wrote: > Anything what links against libedataserverui or the evolution > libraries > should not use WebKit1, only WebKit2 (or no WebKit, of course), > because > these two cannot be mixed in runtime. That was the reason why > the evolution-data-server wasn't ported yet, because the evolution > was > still using WebKit1 and it links against libedataserverui. Please note that this kills Bijiben, we'll need to tell distros to remove it unless bug #728293 gets fixed very soon. 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
