Re: Problems regarding jhbuild

[Jürg Billeter]

Hi Michael,

On Mon, 2016-10-10 at 14:49 -0500, Michael Catanzaro wrote:
> Anyway, the problem is a bootstrap version of vala needs to be
> installed as a sysdep, but we can't make a sysdep for it until the vala
> developers stop pointlessly bumping their pkg-config version early
> single release. We need one vala pkg-config file that's sure to be
> installed, then we can add a sysdep for it. In the meantime the only
> workaround is to just install vala with your distro's package manager.

The pkg-config file is for libvala, which provides access to Vala's
internals and is not API-stable, hence the parallel installable
versions. However, it's also not needed by regular applications and
libraries that are written in Vala.

For bootstrapping, the dependency should be on valac, not on libvala.
I'm not very familiar with jhbuild but what's the issue with a valac
sysdep such as the following, similar to how the C compiler sysdep is
handled?



Regards,
Jürg
___
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: Problems regarding jhbuild

[Michael Catanzaro]

On Tue, 2016-10-11 at 01:03 +0530, Abishek Kumar wrote:
> can anyone of you help me with this. I would really like to
> contribute to
> gnome from here on. Thanks in advance.

Hi,

This vala build error was actually the last straw when I decided to
remove Ubuntu from the list of supported distros. Clearly nobody is
maintaining the jhbuild modulesets to ensure they work on anything not
Fedora.

Anyway, the problem is a bootstrap version of vala needs to be
installed as a sysdep, but we can't make a sysdep for it until the vala
developers stop pointlessly bumping their pkg-config version early
single release. We need one vala pkg-config file that's sure to be
installed, then we can add a sysdep for it. In the meantime the only
workaround is to just install vala with your distro's package manager.

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

Re: Problems regarding jhbuild

[Christian Hergert]

On 10/10/2016 12:33 PM, Abishek Kumar wrote:

*** Checking out vala *** [20/30]
git remote set-url origin git://git.gnome.org/vala

git remote update origin
Fetching origin
git rebase origin/0.34
Current branch 0.34 is up to date.
*** Configuring vala *** [20/30]
./autogen.sh --prefix /home/hulkbuster/jhbuild/install --disable-Werror
--enable-vapigen --disable-static --disable-gtk-doc
./autogen.sh: 10: ./autogen.sh: valac: not found
**Error**: You must have valac >= 0.12.0 installed
  to build vala. Download the appropriate package
  from your distribution or get the source tarball at
  http://download.gnome.org/sources/vala/
*** Error during phase configure of vala: ## Error running
./autogen.sh --prefix /home/hulkbuster/jhbuild/install --disable-Werror
--enable-vapigen --disable-static --disable-gtk-doc  *** [20/30]


I'm not the most up to date person on Vala, but I do believe it is 
similar to GCC in that you need to bootstrap. So you'll need a Vala 
compiler to compile Vala).


Your distribution probably has one that can be installed. Such as:

  sudo dnf install vala (for Fedora)

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

Problems regarding jhbuild

[Abishek Kumar]

Hey

I am facing difficulty in building the JHbuild from the below instruction
page:
https://wiki.gnome.org/Newcomers/BuildGnome

I get the below error when i run the following command:

$jhbuild build adwaita-icon-theme dconf glib-networking gvfs libcanberra



*** Checking out vala *** [20/30]
git remote set-url origin git://git.gnome.org/vala
git remote update origin
Fetching origin
git rebase origin/0.34
Current branch 0.34 is up to date.
*** Configuring vala *** [20/30]
./autogen.sh --prefix /home/hulkbuster/jhbuild/install --disable-Werror
--enable-vapigen --disable-static --disable-gtk-doc
./autogen.sh: 10: ./autogen.sh: valac: not found
**Error**: You must have valac >= 0.12.0 installed
  to build vala. Download the appropriate package
  from your distribution or get the source tarball at
  http://download.gnome.org/sources/vala/
*** Error during phase configure of vala: ## Error running
./autogen.sh --prefix /home/hulkbuster/jhbuild/install --disable-Werror
--enable-vapigen --disable-static --disable-gtk-doc  *** [20/30]

  [1] Rerun phase configure
  [2] Ignore error and continue to build
  [3] Give up on module
  [4] Start shell
  [5] Reload configuration
  [6] Go to phase "wipe directory and start over"
  [7] Go to phase "clean"
  [8] Go to phase "distclean"
choice:

can anyone of you help me with this. I would really like to contribute to
gnome from here on. Thanks in advance.

Best regards
abishek
___
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

[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&a=tree&h=a6fa7cd83f0fbae52
4a63952c3c3bf607b7566d0&hb=f187eaf9ff7b3994de649377abf18f131fee03ef&f=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. 

___
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

[Milan Crha]

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

Maintainer needed for Bijiben

[aday]

Hi all,

The Notes app (also known as Bijiben) needs some new blood. It has been 
slipping recently and is probably going to end up being dropped 
altogether. This would be a real shame because a lot of work has gone 
into it and it has loads of potential. On the design side we have lots 
of plans for the app and there are many cool possibilities for things 
we could do with it. Also, every operating system needs a good built-in 
notes app; it would be sad if GNOME doesn't have one!


Bijiben's bugzilla is in a good state and Pierre-Yves, the current 
maintainer, is happy to help a new recruit get up to speed. It's mostly 
written in C. The most pressing issue is either to upgrade to WebKit2 
or drop WebKit in favour of GTK+.


Any takers?! :)

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

Some dudes opinion on Ctrl-Tab

[Daniel Beecham]

I'm sorry about bumping issue, but I'd like to give my two cents and see if
you'd like to reconsider this issue.




First, the argument of popularity.

+ All major web browsers (Firefox, Chrome, Edge, Internet Explorer, Opera,
Midori and others) use ctrl-tab to switch tab. Neither  nor
 consumes tab in any of these browsers, it's just used to change
focus.
Epiphany (Web) used to use ctrl-tab to switch tabs, but I that changed.

+ Visual studio, visual studio code, intellij, code:blocks, atom, sublime
text, brackets (and practically all other editors except vim and emacs) use
ctrl-tab to switch tab. Tab is consumed.

Switching focus in these is usually harder. You can sometimes switch focus
to the menu bar by pressing Alt (single press, key-down-key-up, no focus
change if you press alt-tab). Switching focus to something else then the
menu bar is harder (you need to know the specific keybinds), but the menu
bar will at least display all the keyboard shortcuts.

+ Matlab only uses ctrl-tab to switch between tabs if the "editor window"
has been "popped out" of the main window, and this is definitely a source
of confusion: http://se.mathworks.com/matlabcentral/answers/?term=switch+tab

+ The wikipedia "list of table shortcuts" lists "ctrl-tab" as "switch tab"
https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts#Tab_management


+ On a more personal note, I'm a representative in a student union in my
university, and confusion over ctrl-tab not switching tab is something I've
seen more then once.


All right, so, people are used to ctrl-tab switching tabs.



* The argument of obviousness ("don't make me think", or "great design is
invisible")

Ctrl-tab is such an ubiquitous binding by now, that users just sort of
expect it. I saw a design talk by some designer on google the other day,
and she talked about how they'd just plop a UI in front of people and see
what they'd do - and then make the UI such that those interactions made
sense. Like A/B testing a'la extreme. You want an interface which is
obvious, which makes sense, is intuitive, doesn't get in your way. Those
are the successful interfaces. ctrl-tab is obvious.

Be successful - be ctrl-tab.




* Just rebind switch tab to ctrl-tab.
That's not possible for some reason? I'm not sure I get this. We need
ctrl-tab to switch control groups, but what if I don't want to switch
control groups, or if I just use my mouse do do that? What if I want to
switch control groups with ctrl-alt-shift-caps-p?





* What about the people that *need* to be able to switch focus, maybe
because an impairment (or that guy not having a mouse)?

This group contains many orders of magnitude fewer people then that other
group. This does not mean that we should screw them over, but do we really
need to assign *ctrl-tab* to that group specifically? They are not used to
be able to do ctrl-tab in any other scenario. We could have ctrl-that wierd
button next to 1, or win-tab, or ctrl-g, or F7. Any user who wants out of
something presses esc; esc could "defocus" a field, and the user could tab
happily ever after.

And also, even if ctrl-tab was de-facto standard for focus switching, I
feel like I should be able to rebind it on my personal computer.



* OK. So what about the users who just don't like "ctrl-tab"?

Why don't they just rebind ctrl-tab to ctrl-page-up?




* Why don't you just use ctrl-page-up? It's not hard to get used to.

My keyboard doesn't have a page-up-button. There are many keyboards out
there that lack such a key, you need to press ctrl-fn-some other button
which isn't always easy to reach.

And also, it's so strange, right, it's not like ctrl-right and ctrl-left,
or ctrl-home and ctrl-end. It's page up and page down. Maybe tabs can be
seen sort of as pages, but they aren't spaced out vertically.



All in all, I'm not sure I understand this decision. None of the arguments
I've seen seem to really hold too much ground.

Now that I've been "that guy", I should go spend time doing something more
productive. Thanks for your consideration.
___
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