Instead of compiling all the dependsies I would recommend to have a look at flatpack_buid.
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.
But flatpack_buld does all the work for you. It creates the container, downloads all dependencies and compiles them. You just need the manifest.
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?
this is a very small package where I added a meson build
search for “export CC=clang”
Okay, I just cloned json-glib, cd-ed into it, made a directory called ‘_build’, and attempted to run the commands you listed. I got as far as ’
ERROR: Target 'Gir' can't be generated as 'g-ir-scanner' could not be found
That seems to be something in the GObject-Introspection dependency, which the README.md says is optional.
So, to sum it up:
git clone https://gitlab.gnome.org/GNOME/json-glib
cd json-lib
mkdir _build
meson _build .
…and that’s as far as I get. Gotta go, datenight with my best friend…
OK, thanks to some helpful replies over on the GIMP developers mailing list (Developers - how to build json-glib in a prefix when building gimp from git in a prefix?), I finally managed to build json-glib and install it in a prefix.
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 need some retirement projects…
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… 
Here’s a clue why Tumbleweed is still on meson 0.46:
https://bugs.gentoo.org/show_bug.cgi?id=666968
Nice phrase! I like that!
here is a thought … instead of building everything from git … only build the really needed things from git. 
This doesn’t happen if you make the text format as inline code, like this:
code ..
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.
@patdavid @paperdigits and other pixls admin and readers: Here is a proposal:
There are three articles on my website on building GIMP:
- Building GIMP for artists and photographers (Building GIMP for artists and photographers)
- Updating GIMP for artists and photographers (Updating GIMP for artists and photographers)
- Build GIMP 2.9 from git, GIMP 2.8, & GIMP 2.6, each in its own prefix (Build GIMP from git, GIMP 2.8, & GIMP 2.6 in prefixes)
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.
Elle,
much as I admire people who build everything from git, that approach has its problems - when something breaks, to which package is the breakage attributable ? I’m talking about run-time breakage, not build-time (although there will often be a lot of that when picking random git commits across multiple packages).
For gimp-2.99, yes, you need a git version for that and perhaps for a few other dependencies. But wherever possible, it is much easier to stick to released versions (and, as I said elsewhere, look at configure and the files for meson - or for cmake on packages using that - to determine what you can get away with).
Of course, even releases have bugs that nobody testing them has yet noticed.
At the moment, I assume that 2.99 is not yet close to a release and therefore only dedicated testers should be using it - in 2.9, may things changed and it can be a pain to have to keen relearning how to do things.
But libre software is supposed to be about having fun - don’t let it grind you down, and enjoy whatever you decide to do.
ĸen
“In 2.9, may things changed” : s/may/many/ for coders, and for everyone else just change ‘may’ to ‘many’.
Hey @Elle, we’ll take care of all 3 articles, provided they’re CC licensed (which I assume wouldn’t be a problem). I can’t say that we can commit to the 2.9, 2.8, and 2.6 versions article, because all of those are are way old, but we’ll at least host the article. Everything of our is in git & on github and we’d certainly accept pull requests on any of it!