Re: Let's kill gnome-common!
On Tue, Feb 13, 2018 at 3:43 AM, Sébastien Wilmet wrote: The list is not complete, there is for example gedit as well, I think it was common to *not* list gnome-common as dependency in the jhbuild modulesets because libraries like gtk was already depending on it. Hm, indeed, gedit does not use gnome-autogen but it does use GNOME_COMPILE_WARNINGS. It must be getting pulled into the build environment by one of its dependencies. Also, I think it's a bit a waste of effort to first port to autoconf-archive macros, and then porting to meson just a few development cycles later. Getting rid of gnome-common takes about 10 minutes at worst, but porting to meson is a much larger effort! Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
On Tue, 2018-02-13 at 15:13 +0100, Frederic Peters wrote: > > On Tue, 2018-02-13 at 11:19 +, Emmanuele Bassi wrote: > > > Work is in progress to let maintainers upload tarballs with the > > > generate API reference for developer.gnome.org > > > > Hi, > > okay, how is that supposed to work in general? As Meson builds out > > of > > the source tree, is that "work in progress" meant to be Meson > > specific? > > Developer.gnome.org still looks for "markers" in source tarballs > (like > include gtk-doc.make in Makefile.am) and use those to extract the > documentation module name (ex: for gtk+ it would extract three doc > modules, gtk4, gdk4, gsk4). > > What's new and in progress is the possibility to map those modules to > external documentation tarballs that will contain the generated HTML > files. > > Some parts of the process are in place already, from manually > generated documentation tarballs for GTK+, published at: > https://download.gnome.org/docs/gtk+/3.93/ > we can now create https://developer.gnome.org/gtk4/3.93/ > > (this is very fresh, literally two days ago) > > Now no maintainer would want the burden to generate those additional > tarballs and they should be automatically created and published by a > CI system (gnome continuous or buildstream or whatever). > > Wrt evolution developer.gnome.org still lacks the code to find the > gtk-doc markers in CMakeLits.txt files. (some experimental code was > added for meson as used in GTK+) I have a few platform-level daemons that could do with having their gtk-doc on developer.gnome.org. Is there an example of what commands would need to be run to create and package the docs, and how to get them installed on gnome.org? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
Milan Crha wrote: > On Tue, 2018-02-13 at 11:19 +, Emmanuele Bassi wrote: > > Work is in progress to let maintainers upload tarballs with the > > generate API reference for developer.gnome.org > > Hi, > okay, how is that supposed to work in general? As Meson builds out of > the source tree, is that "work in progress" meant to be Meson specific? Developer.gnome.org still looks for "markers" in source tarballs (like include gtk-doc.make in Makefile.am) and use those to extract the documentation module name (ex: for gtk+ it would extract three doc modules, gtk4, gdk4, gsk4). What's new and in progress is the possibility to map those modules to external documentation tarballs that will contain the generated HTML files. Some parts of the process are in place already, from manually generated documentation tarballs for GTK+, published at: https://download.gnome.org/docs/gtk+/3.93/ we can now create https://developer.gnome.org/gtk4/3.93/ (this is very fresh, literally two days ago) Now no maintainer would want the burden to generate those additional tarballs and they should be automatically created and published by a CI system (gnome continuous or buildstream or whatever). Wrt evolution developer.gnome.org still lacks the code to find the gtk-doc markers in CMakeLits.txt files. (some experimental code was added for meson as used in GTK+) Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
On Tue, 2018-02-13 at 11:19 +, Emmanuele Bassi wrote: > Work is in progress to let maintainers upload tarballs with the > generate API reference for developer.gnome.org Hi, okay, how is that supposed to work in general? As Meson builds out of the source tree, is that "work in progress" meant to be Meson specific? Personally, I'd not include those gtk-doc and help generated files in the tarballs, because they are there "twice" then, but I know of the older thread where some distro(s) preferred in-tarball documentation over generating them during build time (which saves time for their users/build machines, in price of larger tarballs for everyone); some distros rebuild help/gtk-doc always, no matter whether they are in the tarball or not. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
Emmanuele Bassi wrote: > > I do not want to steal the thread, but when talking about ports to > > Meson, would it make sense to finally fix the infrastructure to work > > with other than automake files too [1]? It's when generating the > > content for developer.|help.gnome.org. Considering that plenty of > > projects already use Meson, either exclusively or as an alternative for > > autotools scripts, then it would be a good idea, from my point of view. > > I'd help myself there, but I do no speak pythonish. I guess someone > > with the knowledge would have that fixed relatively quickly. > > Work is in progress to let maintainers upload tarballs with the > generate API reference for developer.gnome.org; I assume > help.gnome.org would follow the same pattern — but of course we only > have one Frederic, so help is indeed welcome. Actually help.gnome.org is different and easier as the mallard files can be converted to HTML without a full build environment (contrary to gtk-doc); a plan is laid out in bugzilla (#785522) and should be quite simple for anybody with some Python experience: https://git.gnome.org/browse/library-web/tree/src/lgo.py#n700 should be updated to detect other cases, like looking for "set(HELPID" in CMakeLists.txt files, or help_files in meson.build. Then https://git.gnome.org/browse/library-web/tree/src/modtypes/mallard.py#n240 should be changed to get the list of mallard files from those CMakeLists.txt/meson.build files. (alternatively it could just take pages and figures and list of languages looking at the filesystem but then it may fail with pages/languages that are present in git but not supposed to be used). Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
On 13 February 2018 at 11:17, Milan Crha wrote: > On Tue, 2018-02-13 at 09:33 +, Philip Withnall wrote: >> porting the build systems of those modules to Meson is another >> legitimate way to port away from gnome-common. It would be the better >> choice in the long run for modules we are going to be maintaining for >> a while. > > Hi, > I do not want to steal the thread, but when talking about ports to > Meson, would it make sense to finally fix the infrastructure to work > with other than automake files too [1]? It's when generating the > content for developer.|help.gnome.org. Considering that plenty of > projects already use Meson, either exclusively or as an alternative for > autotools scripts, then it would be a good idea, from my point of view. > I'd help myself there, but I do no speak pythonish. I guess someone > with the knowledge would have that fixed relatively quickly. Work is in progress to let maintainers upload tarballs with the generate API reference for developer.gnome.org; I assume help.gnome.org would follow the same pattern — but of course we only have one Frederic, so help is indeed welcome. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
On Tue, 2018-02-13 at 09:33 +, Philip Withnall wrote: > porting the build systems of those modules to Meson is another > legitimate way to port away from gnome-common. It would be the better > choice in the long run for modules we are going to be maintaining for > a while. Hi, I do not want to steal the thread, but when talking about ports to Meson, would it make sense to finally fix the infrastructure to work with other than automake files too [1]? It's when generating the content for developer.|help.gnome.org. Considering that plenty of projects already use Meson, either exclusively or as an alternative for autotools scripts, then it would be a good idea, from my point of view. I'd help myself there, but I do no speak pythonish. I guess someone with the knowledge would have that fixed relatively quickly. Thanks and bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=785522 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
On Mon, Feb 12, 2018 at 07:08:34PM -0600, mcatanz...@gnome.org wrote: > I want to remove gnome-common from our BuildStream projects, but a few > modules are still depending on it: gcr, gnome-autoar, libnotify, > adwaita-icon-theme, gnome-menus, and gsettings-desktop-schemas. The list is not complete, there is for example gedit as well, I think it was common to *not* list gnome-common as dependency in the jhbuild modulesets because libraries like gtk was already depending on it. Also, I think it's a bit a waste of effort to first port to autoconf-archive macros, and then porting to meson just a few development cycles later. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
Thanks Bastien. > Or better port to meson. Yeah that sounds like a better task. Carlos Soriano GNOME Board of Directors On 13 February 2018 at 10:20, Bastien Nocera wrote: > On Tue, 2018-02-13 at 10:08 +0100, Carlos Soriano wrote: > > Hi Michael, > > > > Could you give some context and explanation on this? I could take the > > gnome-autoar, but need to know why this is wanted and the alternative > > to gnome-common. > > When the wiki comes back: > https://wiki.gnome.org/Projects/GnomeCommon/Migration > > Discussion dates back from May 2015. > > Or better port to meson. > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
On Tue, 2018-02-13 at 10:08 +0100, Carlos Soriano wrote: > Hi Michael, > > Could you give some context and explanation on this? I could take the > gnome-autoar, but need to know why this is wanted and the alternative > to gnome-common. When the wiki comes back: https://wiki.gnome.org/Projects/GnomeCommon/Migration Discussion dates back from May 2015. Or better port to meson. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
On Tue, 2018-02-13 at 10:08 +0100, Carlos Soriano wrote: > Hi Michael, > > Could you give some context and explanation on this? I could take the > gnome-autoar, but need to know why this is wanted and the alternative > to gnome-common. Handily all written up a while ago: https://wiki.gnome.org/Projects/GnomeCommon/Migration This was written up before Meson was a thing; porting the build systems of those modules to Meson is another legitimate way to port away from gnome-common. It would be the better choice in the long run for modules we are going to be maintaining for a while. Philip > On 13 February 2018 at 02:08, wrote: > > Hi, > > > > I want to remove gnome-common from our BuildStream projects, but a > > few modules are still depending on it: gcr, gnome-autoar, > > libnotify, adwaita-icon-theme, gnome-menus, and gsettings-desktop- > > schemas. > > > > If you help fix these sad modules, you'll earn the right to say > > that you helped fix these sad modules. > > > > Thanks, > > > > 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 signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
Hi Michael, Could you give some context and explanation on this? I could take the gnome-autoar, but need to know why this is wanted and the alternative to gnome-common. Cheers On 13 February 2018 at 02:08, wrote: > Hi, > > I want to remove gnome-common from our BuildStream projects, but a few > modules are still depending on it: gcr, gnome-autoar, libnotify, > adwaita-icon-theme, gnome-menus, and gsettings-desktop-schemas. > > If you help fix these sad modules, you'll earn the right to say that you > helped fix these sad modules. > > Thanks, > > 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
Let's kill gnome-common!
Hi, I want to remove gnome-common from our BuildStream projects, but a few modules are still depending on it: gcr, gnome-autoar, libnotify, adwaita-icon-theme, gnome-menus, and gsettings-desktop-schemas. If you help fix these sad modules, you'll earn the right to say that you helped fix these sad modules. Thanks, Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list