My own goal wasn’t to build GIMP from source specifically on OpenSUSE. I don’t actually even run OpenSUSE on my main computer (I run Gentoo). I was just trying to update my “how to build” instructions (for any version of Linux) by running through all the steps using OpenSUSE.
I have up-to-date Tumbleweed on the upstairs computer, and so likely I don’t even need to build json-glib at all for that computer. But some people will need to install json-glib from source on their computers, if they want to install GIMP from source. So it would be nice to know the exact commands to type, not just for OpenSUSE, but in general.
GNOME has made it a goal to port its projects to Meson.[14] As of late 2017, GNOME Shell itself exclusively requires Meson after abandoning Autotools,[15] and central components like GTK+, Clutter-GTK, GLib and GStreamer can be built with Meson.[14]
Systemd relies on Meson since dropping Autotools in version 234.[16]
Efforts are made to port Xorg[17] and Mesa[18] to Meson.
OK, if meson is something that one can’t avoid in the future, at least for gtk software, it would be nice if those people trying to build software from source would have some nice easy-to-follow examples.
“The only thing to note is that you need to create a separate build directory. Meson will not allow you to build source code inside your source tree. All build artifacts are stored in the build directory. This allows you to have multiple build trees with different configurations at the same time. This way generated files are not added into revision control by accident.”
autotools lets you build right in the root directory. If you’re using a git clone, or need to build for multiple architectures, this can vex you.
in json-glib, mkdir build, cd build, and try from there…
even for a flatpak/appimage/snap … you are building all the dependencies. you just install them into a special container format instead of your system. both ways will work just fine.
I am not planning to build or download or whatever one needs to do to work with flatpak. I’m sure it’s the greatest thing since hotcakes were invented. But I don’t want to learn how to use flatpak.
OK, starting over this time on my Gentoo computer (so I don’t have to keep running upstairs to the other computer) :
I already have dev-util/meson-0.46.1 installed from portage.
At the command line I established my prefix for building GIMP from git.
I cloned json-glib.
I cd’ed to the just-cloned json-glib source code folder.
Now what do I type next? Do I make a build folder inside the json-glib folder? If so, what do I call it?
Here are sample commands in case anyone else ever needs to build json-glib using meson. This is for building on Gentoo to install in my GIMP-2.99 prefix - Gentoo portage version of json-glib is plenty current enough to build babl/GEGL/GIMP from git - this is just a test build to verify the process:
git clone https://gitlab.gnome.org/GNOME/json-glib
$PREFIX=PREFIX=$HOME/code-install/gimp299/install
cd json-glib
mkdir build
cd build
meson --prefix=$PREFIX ..
ninja install
The above commands did install json-glib in the indicated prefix.
If you need a specific version of json-glib, of course download and unpack the appropriate tarball. As @ggbutcher indicated, an easy way to find the current location of the latest tarballs - for any Linux library, not just for json-glib - is to search for how to build that library for Linux from Scratch.
Reading further about meson/ninja, I may have to try it for rawproc. Geesh, after a year I had finally figured out autotools…
Thing is, I’ve done this a couple of times now, most recently for cmake, and I’ve always come back to autotools for two reasons: 1) it does it all, and 2) it’s the predominant build system in the libraries upon which I depend, so my autotools files work ok with them. Even with autotools, there were times I almost reverted back to my hack Makefile, which is still in the source tree.
Well, I think you’d be better off thinking about porting to qt. But I don’t really know enough about what that would involve to be saying such things.
Or else stick with what you are currently using. After getting the correct commands to type I installed json-glib using meson without any problems on Gentoo. But on OpenSUSE Tumbleweed, even with the correct commands I’ve encountered two problems:
The version of meson shipping with Tumbleweed is 0.46 (get it? This stuff hasn’t even reach 1.0, which would presumably be the first “deemed stable” version of meson). But json-glib wants 0.48 on OpenSUSE, not sure why, I cloned from the same repository on the same day on both Gentoo and OpenSUSE. So my attempt to build json-glib failed on OpenSUSE at the meson --prefix=$PREFIX .. command, though it succeeded on Gentoo - @patdavid - why is the forum software turning my two dots into three dots?
So I used the OpenSUSE software search to locate a repository that provides meson 0.48 and installed it and tried again. This time the build failed on the “ninja install” command with the error that somehow OpenSUSE has the wrong libselinux library.
Which I don’t even have selinux installed at all on Gentoo, so there is probably a way to tell meson to not use selinux on OpenSUSE when installing something in a prefix. But I don’t know how to pass such an option - if indeed such an option can be passed in such a gnome-centric software as meson or json-glib.
So my attempt to update my instructions for building GIMP from source has come to a dead end. It works on Gentoo, not on OpenSUSE Tumbleweed, and I simply do not want to invest any more time in this venture.
If someone really can supply the missing information in an immediately useable form (type exactly this, do exactly that), I’ll continue my efforts to update my how to build GIMP page. In the meantime, it’s just not worth it to me to continue beating my head against this particular brick wall.
Oh, that’s on the list, too. Probably part-and-parcel with a reorg of rawproc; I generally like the tool chain approach, but the UI and batch workflow bear improvement.
Building image applications from source is a complicated mess of library dependencies. Thing is, unless you (a programmer) want to write all that jpeg/png/raw/tiff/cms/lensfun stuff from scratch, you’re stuck being a build-mother of a bunch of unruly children…
What is needed from git varies from one distribution to another. As the person who wrote the articles, I don’t know what will be needed on distribution A vs distribution B. I do know what libraries people using distribution A or distribution B or distribution C have written to me saying they needed help with installing additional missing dependencies. So I’ve tried to include in my articles download links and install directions for such libraries.
I no longer want the burden of trying to keep these articles up-to-date. But I think it’s important that users have a helping hand w.r.t learning to build GIMP and other free/libre software: Successfully building free/libre software is the first step towards being able to contribute code to one’s favorite free/libre software, and perhaps towards becoming a developer of new free/libre software.
So if my three articles have anything worth preserving and updating - this really is a big if even in my own mind, so please don’t feel like my feelings will be hurt if these articles are not a good fit with pixls.us - then my proposal is that I turn these articles over to pixls.us to be rewritten/updated/repurposed/etc as anyone sees fit. And I’ll just point people who visit these articles on my own website to the pixls.us versions as being more recently updated.
If indeed this transfer of the three articles to pixls.us actually happens. I know it would involve work and I absolutely do not want to do any of the work other than reviewing to see if the revised steps actually do work on Gentoo and on OpenSUSE Tumbleweed, these being the two versions of Linux readily available to me. Other people would need to check to see if the steps work on other versions of Linux. And of course the articles would need extensive revision to include Windows and/or Mac, if anyone wanted to do that.
Otherwise I’m just reverting to my initial plan A, which is posting an apology that the articles do already need revision now and will need further revision in the future as Linux software continues to change, but that I’m not prepared to do the necessary revisions to keep the articles up-to-date.