@kugel- pushed 1 commit.

2bd80676b9d75783aa24aa8c63376c2f06a03afb travis for meson

@kugel- pushed 1 commit.

b3d157714e29e733ccbc067412f46debd7048fb0 meson 0.45 compat and -O2

I don't know Meson and didn't review the Meson related changes. But the rest looks OK, I guess preferring `PACKAGE_VERSION` over `VERSION` is better for Meson and doesn't matter for Autotools?

Would it help for the Windows part to merge it first?

Needs to update docs describing how to use the meson build system with Geany, otherwise nobody will use it because its not documented.

README HACKING INSTALL geany.txt

all cover various parts of autofools and need meson instructions too. Suggest you cover it in detail (commands, options, prefixes, and other stuff those docs cover) in one place, then refer to that from the others. That will avoid issues of inconsistent and missing information in different places.

Seems meson installs .so files to `$PREFIX/lib/x86_64-linux-gnu` not `$PREFIX/lib`. Linking from `$PREFIX/lib/libgeany.so.0` works, but needs to be fixed properly.

Sorry, Linux Mint 20 meson 0.54

@elextr commented on this pull request.

• 'src/utils.h',

+ 'src/vte.c', + 'src/vte.h', + gen_src, + soversion: '0', + c_args: geany_cflags, + include_directories: [iscintilla], + dependencies: [dep_tagmanager, dep_ctags, dep_scintilla] + deps, + install: true) + +executable('geany', 'src/main.c', + link_with: libgeany, + c_args: geany_cflags, + dependencies: [dep_ctags] + deps, + build_rpath: meson.build_root(), + install_rpath: join_paths(prefix, 'lib'),

@kugel- here is why rpath is set to `$PREFIX/lib` but I can't find how in meson docs to find where libraries are installed but clearly its different for different systems but this needs to be set to it (or the install set).

@kugel- pushed 5 commits.

3d73cdd7d30a35adfbb85cf09e9b4cc51bb001c9 fix geany.pc 16249f54708c3f98f5d99589972ffabcaa2e9b5e hopefully fix debian/ubuntu c022ca856713f9d2891e39bf2914946d0be814f6 fix internal dependencies f9765e9a1035aed8b9c63c84cb37529090a6b7f9 tiny cleanup a772beb02032011c6bdbb5da336bb7fe588a0012 mingw workaround (FIXME)

I support @elextr's request for docs, https://github.com/geany/geany/pull/2761#issuecomment-809698447 helped.

On configure, I got: ``` po/meson.build:6:4: ERROR: Problem encountered: /bin/sh: 1: gawk: not found ``` which seems to be a new dependency. As it is just used (AFAIK) to generate a list of names of the available languages, this can done also with a Python oneliner or maybe even with Meson itself?

At the end of the compilation I got a few warnings which might be interesting: ``` msgfmt: ../po/LINGUAS does not exist ../geany.desktop.in:5:0: warning: invalid non-blank line ../geany.desktop.in:6:0: warning: invalid non-blank line ../geany.desktop.in:7:0: warning: invalid non-blank line ../geany.desktop.in:14:0: warning: invalid non-blank line [247/247] Linking target plugins/libsplitwindow.so meson compile -C build 464.85s user 38.27s system 353% cpu 2:22.13 total ``` Tested on ArchLinux and Debian Testing.

For reference, here is my `geany.desktop.in`: ``` [Desktop Entry] Type=Application Version=1.0 _Name=Geany _GenericName=Integrated Development Environment _Comment=A fast and lightweight IDE using GTK+ Exec=geany %F Icon=geany Terminal=false Categories=GTK;Development;IDE;TextEditor; MimeType=text/plain;text/x-chdr;text/x-csrc;text/x-c++hdr;text/x-c++src;text/x-java;text/x-dsrc;text/x-pascal;text/x-perl;text/x-python;application/x-php;application/x-httpd-php3;application/x-httpd-php4;application/x-httpd-php5;application/xml;text/html;text/css;text/x-sql;text/x-diff; StartupNotify=true _Keywords=Text;Editor; ```

Geany plugins with autotools configures against Geany built with meson but fails to build:

``` CC libgeanypluginutils_la-filelist.lo filelist.c:27:10: fatal error: geanyplugin.h: No such file or directory 27 | #include <geanyplugin.h> | ^~~~~~~~~~~~~~~ ```

because meson build of geany did not install anything to `$PREFIX/include/geany`

Thanks for your feedback!

This is still a WIP and a lot of stuff is missing. I'll try to fix all of that, but what I want is a clear sign that I won't waste my time because nobody would approve this. I have too much other stuff rotting in PRs already.

Thanks that was the clear sign I was waiting for. Apparently it was not clear enough yet :-) I'll work on it further then.

Btw, I could also offer my own build system, https://github.com/kugel-/kmake/, this replaces Automake by pure (GNU) make. It's a huge improvement over Automake (accurate dependencys, no busted checkouts by badly generated Makefiles and more). But I'm not sure it's truly useful for Geany because Geany's pain is more on the autoconf than on the Automake side and kmake isn't really tested for Windows stuff.

I do use kmake for Peasy though and it's great (and peasy is much more than compiling C files)

@kugel- pushed 1 commit.

3380d1072edc3c2b6363e7d3250c010dcd4536a3 initial docs

@kugel- pushed 1 commit.

3f26c8820ef6b0e42f5094a291b1db02c24c22c4 rework i18n support to not use wildcard sources

@kugel- pushed 3 commits.

5061b593d08c7b25d57afb632d918b4e0be4c3c2 fixed geany.1 man page 9e8f79e956c00b759f7abd39499397e9c417b10a Doxyfile per Makefile anstat per configure 0168e6feb0d4332d1d12b331700b1595a5d55328 meson: doc completed

@kugel- pushed 1 commit.

7315a62ee8e9af15b9b3e428ad792cabc3069a9b tests

Still has [classviewer icons](https://github.com/geany/geany/pull/2761#issuecomment-813147411) messages at runtime, added checkbox as reminder.

Still has classviewer icons messages at runtime, added checkbox as reminder.

I don't see that; weird, but since I don't do anything to install those yet, I guess there is something missing. Maybe my meson-geany gets the icons from my system-geany from /usr/local/... ?

...

Geany plugins now build if configured --prefix=/home/lex/geany_meson --with-geany-libdir=/home/lex/geany_meson/lib and install to $PREFIX/lib/geany but do not appear in plugin manager.

You have to use the correct libdir, obviously, i.e. --with-geany-libdir=/home/lex/geany_meson/lib/x86_64-linux-gnu. Typically you avoid setting --with-geany-libdir and instead point pkg-config to the correct geany.pc. Under ubuntu, geany.pc has this line: libdir=${exec_prefix}/lib/x86_64-linux-gnu

As I said configuring ` --with-geany-libdir=/home/lex/geany_meson/lib/x86_64-linux-gnu` fails. According to @hyperair when this option was added, this is the "proper" way of configuring this for Debian and derivative systems. But anyway until G-P is mesoned (meson subprojects might be a good fit?) it needs to work.

On this system _all_ the system pkg-configs are under `x86_64-linux-gnu/pkgconfig` so a geany installed to the system would be out of place and not found if it installed in `lib/pkgconfig`.

It seems like there are still things being installed in a mixture of `lib` and `lib/x86_64-linux-gnu` whereas it should all be the latter if thats the system default determined by meson. I guess its hard to notice on your system if `lib` is the default, but the meson build should never force `lib`.

Maybe my meson-geany gets the icons from my system-geany from /usr/local/... ?

The advantage of my habit of _only_ using prefixed geanys and having no system install :-)

The meson build isn't installing `$PREFIX/share/icons` which is likely the problem.

Ping.

As I said configuring --with-geany-libdir=/home/lex/geany_meson/lib/x86_64-linux-gnu fails.

Can you please paste the exact error message?

mentioned on IRC, just FTR

``` checking for GEANY... no configure: error: Package requirements (geany >= 1.29) were not met:

No package 'geany' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. ```

@elextr commented on this pull request.

+act_icons = {'16x16': actions,

+ '24x24': actions, + '32x32': actions, + '48x48': actions} + +icons_dir = join_paths(get_option('datadir'), 'icons', 'hicolor') +icons_appsdir = join_paths(icons_dir, 'apps') +icons_actionsdir = join_paths(icons_dir, 'actions') + +foreach dir, icons_array : app_icons + foreach icon : icons_array + install_data(join_paths(dir, icon), install_dir: icons_appsdir) + endforeach +endforeach + +foreach dir, icons_array : app_icons

@kugel- shouldn't this be act_icons?

@kugel- commented on this pull request.

+act_icons = {'16x16': actions,

+ '24x24': actions, + '32x32': actions, + '48x48': actions} + +icons_dir = join_paths(get_option('datadir'), 'icons', 'hicolor') +icons_appsdir = join_paths(icons_dir, 'apps') +icons_actionsdir = join_paths(icons_dir, 'actions') + +foreach dir, icons_array : app_icons + foreach icon : icons_array + install_data(join_paths(dir, icon), install_dir: icons_appsdir) + endforeach +endforeach + +foreach dir, icons_array : app_icons

yea

@kugel- Sorry for the delay on my side - is there anything macOS specific that should be addressed? In general, there should be no problem with meson on macOS - I build all the dependencies of Geany from sources and many of them use meson already and work alright.

  I wonder if the missing `../po/LINGUAS` is a problem and what's the consequence.
  The lines about "warning: invalid non-blank line" seems to be related that Meson is using `gettext` to process the .desktop file where previously `intltool` was used. And the `_Keyword...` syntax is specific for `intltool`.
  It seems this might be a seperate task like migrating from `intltool` to `gettext` (https://stackoverflow.com/questions/62504873/i18n-merge-file-cant-translate-desktop-file).
  Anyway, we need to handle this in some way as the resulting .desktop file is missing items like "Name", "Comment" and "Keywords".

I think this is what the [i18n.merge_file()](https://mesonbuild.com/i18n-module.html#i18nmerge_file) function was designed for (note the 'type' keyword).

@techee you specify the prefix when you initialize the build directory, see https://github.com/geany/geany/pull/2761#issuecomment-809698447

The error looks like g++ is using the wrong standard, @kugel- hasn't specified it and I guess all the rest of us are using a g++ that defaults to at least c++11. In fact the new Julia lexer requires c++17 so you will need a compiler capable of that (see recent changes to travis distro version on geany-plugins to get new enough compilers).

OK, with

``` meson _builddir -Dgtkdoc=false -Dcpp_std=c++17 && ninja -C _builddir -j 1 -v ```

I got a bit further now:

``` [230/252] /Applications/Xcode.app/Contents/Developer/usr/bin/g++ -o libgeany.0.dylib libgeany.0.dylib.p/src_about.c.o libgeany.0.dylib.p/src_build.c.o libgeany.0.dylib.p/src_callbacks.c.o libgeany.0.dylib.p/src_dialogs.c.o libgeany.0.dylib.p/src_document.c.o libgeany.0.dylib.p/src_editor.c.o libgeany.0.dylib.p/src_encodings.c.o libgeany.0.dylib.p/src_filetypes.c.o libgeany.0.dylib.p/src_geanyentryaction.c.o libgeany.0.dylib.p/src_geanymenubuttonaction.c.o libgeany.0.dylib.p/src_geanyobject.c.o libgeany.0.dylib.p/src_geanywraplabel.c.o libgeany.0.dylib.p/src_highlighting.c.o libgeany.0.dylib.p/src_keybindings.c.o libgeany.0.dylib.p/src_keyfile.c.o libgeany.0.dylib.p/src_log.c.o libgeany.0.dylib.p/src_libmain.c.o libgeany.0.dylib.p/src_msgwindow.c.o libgeany.0.dylib.p/src_navqueue.c.o libgeany.0.dylib.p/src_notebook.c.o libgeany.0.dylib.p/src_plugins.c.o libgeany.0.dylib.p/src_pluginutils.c.o libgeany.0.dylib.p/src_prefs.c.o libgeany.0.dylib.p/src_printing.c.o libgeany.0.dylib.p/src_project.c.o libgeany.0.dylib.p/src_sciwrappers.c.o libgeany.0.dylib.p/src_search.c.o libgeany.0.dylib.p/src_socket.c.o libgeany.0.dylib.p/src_spawn.c.o libgeany.0.dylib.p/src_stash.c.o libgeany.0.dylib.p/src_symbols.c.o libgeany.0.dylib.p/src_templates.c.o libgeany.0.dylib.p/src_toolbar.c.o libgeany.0.dylib.p/src_tools.c.o libgeany.0.dylib.p/src_sidebar.c.o libgeany.0.dylib.p/src_ui_utils.c.o libgeany.0.dylib.p/src_utils.c.o libgeany.0.dylib.p/src_vte.c.o -L/Users/jhbuild/gtk/inst/lib -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include -I/Users/jhbuild/gtk/inst/include -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -Wl,-undefined,error -shared -install_name @rpath/libgeany.0.dylib -compatibility_version 0 -current_version 0 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mmacosx-version-min=10.13 -Wl,-headerpad_max_install_names -O2 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mmacosx-version-min=10.13 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk libtagmanager.a libctags.a libscintilla.a /Users/jhbuild/gtk/inst/lib/libglib-2.0.dylib /Users/jhbuild/gtk/inst/lib/libintl.dylib /Users/jhbuild/gtk/inst/lib/libgmodule-2.0.dylib /Users/jhbuild/gtk/inst/lib/libgtk-3.dylib /Users/jhbuild/gtk/inst/lib/libgdk-3.dylib -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,CoreGraphics /Users/jhbuild/gtk/inst/lib/libpangocairo-1.0.dylib /Users/jhbuild/gtk/inst/lib/libpango-1.0.dylib /Users/jhbuild/gtk/inst/lib/libharfbuzz.dylib /Users/jhbuild/gtk/inst/lib/libatk-1.0.dylib /Users/jhbuild/gtk/inst/lib/libcairo-gobject.dylib /Users/jhbuild/gtk/inst/lib/libcairo.dylib /Users/jhbuild/gtk/inst/lib/libgdk_pixbuf-2.0.dylib /Users/jhbuild/gtk/inst/lib/libgio-2.0.dylib /Users/jhbuild/gtk/inst/lib/libgobject-2.0.dylib -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,CoreGraphics -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,CoreGraphics FAILED: libgeany.0.dylib /Applications/Xcode.app/Contents/Developer/usr/bin/g++ -o libgeany.0.dylib libgeany.0.dylib.p/src_about.c.o libgeany.0.dylib.p/src_build.c.o libgeany.0.dylib.p/src_callbacks.c.o libgeany.0.dylib.p/src_dialogs.c.o libgeany.0.dylib.p/src_document.c.o libgeany.0.dylib.p/src_editor.c.o libgeany.0.dylib.p/src_encodings.c.o libgeany.0.dylib.p/src_filetypes.c.o libgeany.0.dylib.p/src_geanyentryaction.c.o libgeany.0.dylib.p/src_geanymenubuttonaction.c.o libgeany.0.dylib.p/src_geanyobject.c.o libgeany.0.dylib.p/src_geanywraplabel.c.o libgeany.0.dylib.p/src_highlighting.c.o libgeany.0.dylib.p/src_keybindings.c.o libgeany.0.dylib.p/src_keyfile.c.o libgeany.0.dylib.p/src_log.c.o libgeany.0.dylib.p/src_libmain.c.o libgeany.0.dylib.p/src_msgwindow.c.o libgeany.0.dylib.p/src_navqueue.c.o libgeany.0.dylib.p/src_notebook.c.o libgeany.0.dylib.p/src_plugins.c.o libgeany.0.dylib.p/src_pluginutils.c.o libgeany.0.dylib.p/src_prefs.c.o libgeany.0.dylib.p/src_printing.c.o libgeany.0.dylib.p/src_project.c.o libgeany.0.dylib.p/src_sciwrappers.c.o libgeany.0.dylib.p/src_search.c.o libgeany.0.dylib.p/src_socket.c.o libgeany.0.dylib.p/src_spawn.c.o libgeany.0.dylib.p/src_stash.c.o libgeany.0.dylib.p/src_symbols.c.o libgeany.0.dylib.p/src_templates.c.o libgeany.0.dylib.p/src_toolbar.c.o libgeany.0.dylib.p/src_tools.c.o libgeany.0.dylib.p/src_sidebar.c.o libgeany.0.dylib.p/src_ui_utils.c.o libgeany.0.dylib.p/src_utils.c.o libgeany.0.dylib.p/src_vte.c.o -L/Users/jhbuild/gtk/inst/lib -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include -I/Users/jhbuild/gtk/inst/include -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -Wl,-undefined,error -shared -install_name @rpath/libgeany.0.dylib -compatibility_version 0 -current_version 0 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mmacosx-version-min=10.13 -Wl,-headerpad_max_install_names -O2 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mmacosx-version-min=10.13 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk libtagmanager.a libctags.a libscintilla.a /Users/jhbuild/gtk/inst/lib/libglib-2.0.dylib /Users/jhbuild/gtk/inst/lib/libintl.dylib /Users/jhbuild/gtk/inst/lib/libgmodule-2.0.dylib /Users/jhbuild/gtk/inst/lib/libgtk-3.dylib /Users/jhbuild/gtk/inst/lib/libgdk-3.dylib -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,CoreGraphics /Users/jhbuild/gtk/inst/lib/libpangocairo-1.0.dylib /Users/jhbuild/gtk/inst/lib/libpango-1.0.dylib /Users/jhbuild/gtk/inst/lib/libharfbuzz.dylib /Users/jhbuild/gtk/inst/lib/libatk-1.0.dylib /Users/jhbuild/gtk/inst/lib/libcairo-gobject.dylib /Users/jhbuild/gtk/inst/lib/libcairo.dylib /Users/jhbuild/gtk/inst/lib/libgdk_pixbuf-2.0.dylib /Users/jhbuild/gtk/inst/lib/libgio-2.0.dylib /Users/jhbuild/gtk/inst/lib/libgobject-2.0.dylib -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,CoreGraphics -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,CoreGraphics Undefined symbols for architecture x86_64: "_JuliaParser", referenced from: _BuiltInParsers in libctags.a(ctags_main_parse.c.o) "_lmJulia", referenced from: _Scintilla_LinkLexers in libscintilla.a(scintilla_src_Catalogue.cxx.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. ```

but it seems the julia parser didn't get compiled.

Quick explain, meson requires all files to be explicitly listed, it doesn't search to see whats in the directories the way make does. Its how meson gets its speed since it doesn't need to rebuild the ninja files every time. Not a lot of impact with Geany, but huge with things like chromium or llvm etc.

Sorry, I have to bust that myth.

1) meson doesn't build anything itself, it just generates ninja build scripts. ninja is doing the heavy work 2) make also requires all files to be listed explicitely, by default. GNU make has an extension that allows wildcards that allows to use dynamic source file lists, but that's evaluated at parse-time (basically by shelling out to a "ls dir/*") and doesn't affect the build speed (perhaps unless you have *huge* directories) 3) ninja is not much faster than Make because most of the time is used by the compiler, naturally, especially with C++ code. Ninja has a reduced syntax so parsing ninja files is a bit faster, but at the expense that it's not recommended to write ninja files by hand.

I would expect that an optimized, i.e. non-recursive, as realized with my [kmake](https://github.com/kugel-/kmake/) system, Make build is about the same speed that ninja builds. make can be blazing fast if used properly, i.e. almost all CPU time is measurably used by the compiler.

meson is *much* faster than autoconf, that's true for sure.

Tried to test on Win10 with Msys2; seems to have some issues with the embedded fnmatch/gnu_regex stuff.

* [Configure Output](https://gist.github.com/codebrainz/0fcbfbfb9bd21d4c06ed542ff636ea46#file-con...) * [Build Output](https://gist.github.com/codebrainz/0fcbfbfb9bd21d4c06ed542ff636ea46#file-bui...)

@codebrainz not sure what the problem is, I would have thought g++ 10 would default to c++17, but maybe I'm wrong, does latest git Geany build with autotools on the same system? If it does build maybe the point I posted above will fix it since it meant the standard wasn't explicit?

@codebrainz not sure what the problem is, I would have thought g++ 10 would default to c++17, but maybe I'm wrong, does latest git Geany build with autotools on the same system?

I think the problem is with fnmatch/gnu_regex libraries which I believe are special for Windows, and possibly just some missing checks/macros to enable them. From the build output, it looks like a bunch of macros are not defined which just cascades into a whole pile of errors. I'm pretty sure Ninja is doing parallel compiles so the output is probably out of order.

It's the same setup I used to build Geany previously, but I didn't try Autotools since pulling latest with the c++17 requirement, though judging by the output, I don't think it has hit that issue (yet).

I'm pretty sure Ninja is doing parallel compiles so the output is probably out of order.

Since ninja buffers output, the messages of different compile commands shouldn't be mixed, but yes the order of the compiles may vary.

I did try to tinker with it a bit, but not too much. I'll try other stuff next time I boot into Windows partition.

Agree with @codebrainz suggested path above.

[STOP PRESS, the reason fnmatch and regex work on Linux (and presumably mac) is that they don't get built, the meson configuration finds the system ones and does not build the ctags internal copies]

The RPATH thing might still be needed when a non-system $PREFIX is used, also there was some fiddling needed (see history above) because here libraries live in `/lib/x86_64-linux-gnu` not in `/lib` and meson knows that, whereas the autotools builder puts everything in `/lib` irrespective, so the RPATH needed adjustment.

@kugel- You're doing the work, so it's your call (and can be discussed/refactored later). It just seems weird to have some stuff in subdirs and most stuff in the main file, and then have separate build artifacts, but not in own subdirs/subprojects; basically just seems a little inconsistent. That said, I don't know what's idiomatic in Meson, so feel free to ignore me :)

@eht16 commented on this pull request.

+# we're using lots of deprecated stuff with gtk3 (often because there is no proper alternative!)

+def_cflags += '-Wno-deprecated-declarations' +def_cflags += '-DGDK_DISABLE_DEPRECATION_WARNINGS' +def_cflags += '-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_32' +def_cflags += '-DGEANY_PREFIX="@0@"'.format(get_option('prefix')) +foreach d : [ 'includedir', 'libdir', 'libexecdir', 'datadir', 'localedir' ] + def_cflags += '-DGEANY_@0@="@1@"'.format(d.underscorify().to_upper(), join_paths(prefix, get_option(d))) +endforeach +def_cflags += '-DGEANY_DOCDIR="@0@"'.format(join_paths(prefix, get_option('datadir'), 'doc')) + +# CFLAGS for everything else, i.e. most of Geany +geany_cflags = def_cflags +have_gcc4_visibility = cc.has_argument('-fvisibility=hidden') +geany_cflags += '-DGEANY_PRIVATE' +if target_machine.system() == 'windows' + geany_cflags += '-DGEANY_EXPORT_SYMBOL="__declspec(dllexport)"'

The quotes around `__declspec(dllexport)` must be removed otherwise we get syntax errors, without the quotes the code compiles.

@eli-schwartz commented on this pull request.

+def_cflags += '-DGDK_DISABLE_DEPRECATION_WARNINGS'

+def_cflags += '-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_32' +def_cflags += '-DGEANY_PREFIX="@0@"'.format(get_option('prefix')) +foreach d : [ 'includedir', 'libdir', 'libexecdir', 'datadir', 'localedir' ] + def_cflags += '-DGEANY_@0@="@1@"'.format(d.underscorify().to_upper(), join_paths(prefix, get_option(d))) +endforeach +def_cflags += '-DGEANY_DOCDIR="@0@"'.format(join_paths(prefix, get_option('datadir'), 'doc')) + +# CFLAGS for everything else, i.e. most of Geany +geany_cflags = def_cflags +have_gcc4_visibility = cc.has_argument('-fvisibility=hidden') +geany_cflags += '-DGEANY_PRIVATE' +if target_machine.system() == 'windows' + geany_cflags += '-DGEANY_EXPORT_SYMBOL="__declspec(dllexport)"' +elif have_gcc4_visibility + geany_cflags += '-fvisibility=hidden'

Use the meson kwarg `gnu_symbol_visibility: 'hidden'` on your build targets, and let the declspec define fill in the support gap for Windows (I think everywhere else should support it, really).

• 'scintilla/lexers/LexPerl.cxx',

+ 'scintilla/lexers/LexPowerShell.cxx', + 'scintilla/lexers/LexProps.cxx', + 'scintilla/lexers/LexPython.cxx', + 'scintilla/lexers/LexPO.cxx', + 'scintilla/lexers/LexR.cxx', + 'scintilla/lexers/LexRuby.cxx', + 'scintilla/lexers/LexRust.cxx', + 'scintilla/lexers/LexSmalltalk.cxx', + 'scintilla/lexers/LexSQL.cxx', + 'scintilla/lexers/LexTCL.cxx', + 'scintilla/lexers/LexTxt2tags.cxx', + 'scintilla/lexers/LexVHDL.cxx', + 'scintilla/lexers/LexVerilog.cxx', + 'scintilla/lexers/LexYAML.cxx', + cpp_std: 'c++17',

This is not a valid kwarg, but it is a valid project option. You can add it to default_options in the project() declaration, or override it per target with `override_options: ['cpp_std=c++17']`

@eli-schwartz commented on this pull request.

+cdata.set_quoted('PACKAGE_BUGREPORT', 'https://github.com/geany/geany/issues')

+cdata.set_quoted('PACKAGE_NAME','Geany') +cdata.set_quoted('PACKAGE_STRING', 'Geany ' + meson.project_version()) +cdata.set_quoted('PACKAGE_VERSION', meson.project_version()) +cdata.set('GETTEXT_PACKAGE', 'PACKAGE') +cdata.set('VERSION', meson.project_version()) +cdata.set('ENABLE_NLS', true) +cdata.set('HAVE_VTE', get_option('vte')) +cdata.set('HAVE_PLUGINS', get_option('plugins')) +cdata.set('GEANY_DATA_DIR', join_paths(prefix, get_option('datadir'), 'geany')) +cdata.set('GEANY_DOC_DIR', join_paths(prefix, get_option('datadir'), 'doc', 'geany')) +cdata.set('top_srcdir', meson.source_root()) +cdata.set('top_builddir', meson.build_root()) + +# for geany.pc (adapted from GTK+) +pcconf = cdata

The automagic module is far less verbose than `pcconf.set('DEPENDENCIES', deps_for_pc)` or redefining a variety of already existing variables.

Additionally, the automagic module will create a geany-uninstalled.pc file which can be used to compile third-party software against uninstalled development versions of geany, which may be useful.

@kugel- yay, built a new clone, Geany works and nothing in `$PREFIX/lib`. :smile:

Geany-plugins (at least the ones I have dependencies for) built and installed in `lib/x86_64-linux-gnu` except for `pluginutils` that spammed `/lib`, but thats not this PRs problem. At least debugger (which uses pluginutils) works.

So all good I would say.

One thing I did notice that it configured with GTKdoc enabled but I didn't have python3-lxml so the build fails. Maybe lxml should be checked in the configure step.

Since the lxml module is only needed if gtkdoc is enabled it would need to test with/without the module depending on the setting.

@kugel- the test fails look like autotools has been broken.

I'm ok with it being merged if the tests pass after the conflict is fixed (showing autotools does in fact still work)

Yea let's address that afterwards. Since I have no mac machine I'll need your help.

@eli-schwartz requested changes on this pull request.

• ['memcpy', '#include <string.h>'],

+ ['mkstemp', '#include <stdlib.h>'], + ['regcomp', '#include <regex.h>'], + ['socket', '#include <sys/socket.h>'], + ['strerror', '#include <string.h>'], + ['strstr', '#include <string.h>'], + ['wcrtomb', '#include <wchar.h>'], + ['wcscoll', '#include <wchar.h>'], +] + +foreach h : check_headers + define = 'HAVE_' + h.underscorify().to_upper() + if cc.has_header(h) + cdata.set(define, 1) + else + cdata.set(define, false)

Several times you do `cdata.get()` on values that could be either int `1` or bool `false`, and that evaluates to a meson syntax error when trying to check the "truthiness" of an integer. It doesn't build by default for me.

Which systems was this tested on? Seems like a system that has none of: glibc, fnmatch, regcomp (all 3 need to evaluate to false for configuration to pass).

Very good point. I'll take a look.

I think it's not yet ready to merge: - it seems this branch contains parts of #2938 ??? - `make distcheck` fails, see log at https://gist.github.com/eht16/792145594d9904e9aa9e8829afbd70f1 - could you rebase onto master to get CI back for this PR? This would probably also uncover the `make distcheck` error - the Meson build fails for me with: `../../home/enrico/projects/geany-meson-kugel/meson.build:155:9: ERROR: Object <[IntegerHolder] holds [int]: 1> of type int does not support the `bool()` operator.`

All tested on current Debian Testing.

@kugel- pushed 1 commit.

7c36b7c4148091223993b299ed2f445df044cce4 fix ci

Ok, works for me on Linux again, Geany-plugins builds against it.

Only a couple of comments from @eht16 on the docs and the CI to go AFAICT.

@kugel- pushed 1 commit.

aa68dc31f5c575ea976c1947426e38ca321b147c no meson compile in 18.04

@kugel- pushed 1 commit.

ef848a86683b1f11e292d4c7bef705092f190857 fixup! Doxyfile per Makefile anstat per configure

@kugel- pushed 1 commit.

23f8b0c75cc8f1e09b35c96cd65108d26928dc99 fix for pascal

@kugel- pushed 1 commit.

f3cd453d414e70cb64f1f92cbacb53f8b7821fd2 fix ci

But I don't think this must be gettinf perfect. Autotools is still the default and the meson build can be improved on master.

I agree on not getting perfect but it should work at least :D.

@kugel- commented on this pull request.

• custom_target('doxygen.stamp',

+ input: dox, + output: ['doxygen.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'], + depends: libgeany, + build_by_default: true) + doxy_xml = custom_target('doxygen-gi.stamp', + input: doxgi, + output: ['doxygen-gi.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'], + depends: libgeany, + build_by_default: true) + custom_target('gtkdoc headers', + input : [doxy_xml], + output: ['geany-gtkdoc.h', 'geany-sciwrappers-gtkdoc.h'], + command: [python, '../scripts/gen-api-gtkdoc.py', join_paths(meson.current_build_dir(), 'xml'), '-d', '.', '-o', '@OUTPUT0@', '--sci-output', '@OUTPUT1@'],

I thought `../scripts/gen-api-gtkdoc.py` would be relative to the `doc/` folder where this meson.build is located. But for commands it seems to be relative to the build directory.

I also do 'install_data("../scintilla/…")` further down in the same meson.build and that seems to work.

@kugel- commented on this pull request.

• dep_doxygen = declare_dependency(sources: ['plugins.dox',

+ 'pluginsignals.c', + 'pluginsymbols.c', + 'stash-example.c', + 'stash-gui-example.c']) + + custom_target('doxygen.stamp', + input: dox, + output: ['doxygen.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'], + depends: libgeany, + build_by_default: true) + doxy_xml = custom_target('doxygen-gi.stamp', + input: doxgi, + output: ['doxygen-gi.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'],

Thinking about it, I think I don't actually need the stamp file as the `custom_target` object can be used as a dependency itself. Inherited from Makefile.am where the stamp file ensures proper ordering.

@kugel- commented on this pull request.

• dep_doxygen = declare_dependency(sources: ['plugins.dox',

+ 'pluginsignals.c', + 'pluginsymbols.c', + 'stash-example.c', + 'stash-gui-example.c']) + + custom_target('doxygen.stamp', + input: dox, + output: ['doxygen.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'], + depends: libgeany, + build_by_default: true) + doxy_xml = custom_target('doxygen-gi.stamp', + input: doxgi, + output: ['doxygen-gi.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'],

Grr, https://github.com/mesonbuild/meson/issues/2320

@kugel- commented on this pull request.

• dep_doxygen = declare_dependency(sources: ['plugins.dox',

+ 'pluginsignals.c', + 'pluginsymbols.c', + 'stash-example.c', + 'stash-gui-example.c']) + + custom_target('doxygen.stamp', + input: dox, + output: ['doxygen.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'], + depends: libgeany, + build_by_default: true) + doxy_xml = custom_target('doxygen-gi.stamp', + input: doxgi, + output: ['doxygen-gi.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'],

If directories as output works then we're green, I'll try

@kugel- commented on this pull request.

• dep_doxygen = declare_dependency(sources: ['plugins.dox',

+ 'pluginsignals.c', + 'pluginsymbols.c', + 'stash-example.c', + 'stash-gui-example.c']) + + custom_target('doxygen.stamp', + input: dox, + output: ['doxygen.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'], + depends: libgeany, + build_by_default: true) + doxy_xml = custom_target('doxygen-gi.stamp', + input: doxgi, + output: ['doxygen-gi.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'],

Also, meson can be a PITA. It seems that I cannot use a `declare_dependency()` object in the `depends:` kwarg of `custom_target()`

@eli-schwartz commented on this pull request.

• dep_doxygen = declare_dependency(sources: ['plugins.dox',

+ 'pluginsignals.c', + 'pluginsymbols.c', + 'stash-example.c', + 'stash-gui-example.c']) + + custom_target('doxygen.stamp', + input: dox, + output: ['doxygen.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'], + depends: libgeany, + build_by_default: true) + doxy_xml = custom_target('doxygen-gi.stamp', + input: doxgi, + output: ['doxygen-gi.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'],

Ah yes... we don't then depend on those man3 pages, we just install them directly.

In that case, your best bet would seem to be a python script `['foo.py', '@OUTPUT@', doxygen, '@INPUT@']` that runs `sys.argv[2:]` and then updates the mtime of the stamp file.

@kugel- commented on this pull request.

• dep_doxygen = declare_dependency(sources: ['plugins.dox',

+ 'pluginsignals.c', + 'pluginsymbols.c', + 'stash-example.c', + 'stash-gui-example.c']) + + custom_target('doxygen.stamp', + input: dox, + output: ['doxygen.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'], + depends: libgeany, + build_by_default: true) + doxy_xml = custom_target('doxygen-gi.stamp', + input: doxgi, + output: ['doxygen-gi.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'],

You can just list the files directly as custom_target depends:

No, I can't :( `depends: [files(…), libgeany],` -> `ERROR: custom_target keyword argument 'depends' was of type array[File | SharedLibrary] but should have been array[BuildTarget | CustomTarget]`

I'm also unable to specify the extra C files as input `input: [doxyfile_gi] + files(…),` -> `[2/14] /usr/bin/sh -c 'doxygen @INPUT0@ && touch doc/doxygen.stamp'`

(INPUT0 should just use the first input file)

@kugel- commented on this pull request.

• dep_doxygen = declare_dependency(sources: ['plugins.dox',

+ 'pluginsignals.c', + 'pluginsymbols.c', + 'stash-example.c', + 'stash-gui-example.c']) + + custom_target('doxygen.stamp', + input: dox, + output: ['doxygen.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'], + depends: libgeany, + build_by_default: true) + doxy_xml = custom_target('doxygen-gi.stamp', + input: doxgi, + output: ['doxygen-gi.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'],

OK. `depend_files` seems to work, but not my shell wrapper: `@OUTPUT@` is not substituted when `command: [sh, '-c', 'doxygen @INPUT@ && touch @OUTPUT@'],` is run: `/usr/bin/sh -c 'doxygen doc/Doxyfile && touch @OUTPUT@'`

@kugel- commented on this pull request.

• dep_doxygen = declare_dependency(sources: ['plugins.dox',

+ 'pluginsignals.c', + 'pluginsymbols.c', + 'stash-example.c', + 'stash-gui-example.c']) + + custom_target('doxygen.stamp', + input: dox, + output: ['doxygen.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'], + depends: libgeany, + build_by_default: true) + doxy_xml = custom_target('doxygen-gi.stamp', + input: doxgi, + output: ['doxygen-gi.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'],

Thanks, your shell magic works.

This all shows me why I don't actually like meson.

@kugel- commented on this pull request.

• dep_doxygen = declare_dependency(sources: ['plugins.dox',

+ 'pluginsignals.c', + 'pluginsymbols.c', + 'stash-example.c', + 'stash-gui-example.c']) + + custom_target('doxygen.stamp', + input: dox, + output: ['doxygen.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'], + depends: libgeany, + build_by_default: true) + doxy_xml = custom_target('doxygen-gi.stamp', + input: doxgi, + output: ['doxygen-gi.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'],

Then let it be `command: [sh, '-c', 'doxygen "@INPUT@" && touch "@OUTPUT@"'],`

Anyway, the root problem is that I can't specify output files in subdirectories, this is the only reason for the stamp file (and shell wrapper) at all. And the discussion on mesonbuild/meson#2320 doesn't look like meson cares much about users.

@eli-schwartz commented on this pull request.

• dep_doxygen = declare_dependency(sources: ['plugins.dox',

+ 'pluginsignals.c', + 'pluginsymbols.c', + 'stash-example.c', + 'stash-gui-example.c']) + + custom_target('doxygen.stamp', + input: dox, + output: ['doxygen.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'], + depends: libgeany, + build_by_default: true) + doxy_xml = custom_target('doxygen-gi.stamp', + input: doxgi, + output: ['doxygen-gi.stamp'], + command: [doxygen, '@INPUT@', '&&', 'touch', '@OUTPUT@'],

The `"` character is one of the "would break a shell script" characters I mentioned.

The root problem of specifying output files in subdirectories is a legitimate point, which nevertheless (fortunately?) does not affect the majority of use cases. For unrelated reasons, I actually do want to add a doxygen function to meson, which *would* be able to do behind the scenes stuff and track output files in subdirectories...

@kugel- pushed 1 commit.

d11bf9b75cba9b8c7bacf452edeeb8f2d6cdefe5 Port to the meson build system.

@kugel- pushed 1 commit.

0cb84fd74c07c75cb06e96591e398ee375e18795 Port to the meson build system.

Any further objects, or good to merge now? Will merge in a few days if nobody speaks up.

It looks pretty good now! Here my full build log: https://gist.github.com/eht16/b38c656d6f2edab62832f181248108c1

Findings: - there is a deprecation notice in https://gist.github.com/eht16/b38c656d6f2edab62832f181248108c1#file-gistfile... but I guess we could keep it for now - Plugins failed to compile first because meson installs geany.pc and the rest of the libs in `$prefix/lib/x86_64-linux-gnu`. I'm not sure if this is OK or not, at least it is different from autotools. With `./configure --prefix=/tmp/install-meson --with-geany-libdir=/tmp/install-meson/lib/x86_64-linux-gnu` Plugins compiled fine. - some files are not or in different locations installed compared to autotools. I added a list of differences in installed files in https://gist.github.com/eht16/b38c656d6f2edab62832f181248108c1#file-differen.... - I did *not* test on Windows, we can do this post-merge

I'd say we should sort out the install differences but then good to merge.

Plugins failed to compile first because meson installs geany.pc and the rest of the libs in $prefix/lib/x86_64-linux-gnu. I'm not sure if this is OK or not, at least it is different from autotools. With ./configure --prefix=/tmp/install-meson --with-geany-libdir=/tmp/install-meson/lib/x86_64-linux-gnu Plugins compiled fine.

Correct, as @eli-schwartz said, on Debians and derivatives the "correct" place is the architecture specific directory `lib/x86_64-linux-gnu`, not in basic `lib`. I expect this is because Debian builds for x86_64 and also ARM and IBM and they need to be separated. So in this case the meson build is more correct than the autotools build and should stay as it is.

So the parts of the @eht16 install diff that relate to this should not be changed.

Do we need to install the `share/doc/geany` files? (noting the licenses are installed in `share/geany`) They are not much use post build. Also note that the fact that the Lexilla license is missing from the Autotools build is a bug that should be fixed #3126.

The Tango icons has only (geany-save-all), why does _only_ this icon have an additional version? Looks more like a bug in the standard build to me.

@kugel- I thought we had fixed the missing scalable icons?

Regarding gtk-update-icon-cache, this is not supported in the minimum meson version. Recently such funtionality (to run scripts after installation within the install directory) was added to the gnome module, see https://github.com/mesonbuild/meson/issues/8268

Does anyone know the impact of running this program (or more specifically, of not running it). My understanding is that packagers don't need it (because they usually set DESTDIR to install the binaries to a staging directory, from where the actual package is created) and run gtk-update-icon-cache as part of the package installation. But what's the impact for custom installation, e.g with prefix = /usr/local or something under $HOME ?

Thanks for the insights. I'm still not sure what's the impact specifically for *geany*. I don't know what badness happens if you run geany without creating the icon cache (I haven't noticed any issues with my local) testing. We don't install lots of images at all (4 per size), maybe not worth?

Is "using the cache" something that's handled transparently by GTK or should there be some specific code inside Geany to support that cache file? I don't know about such code but maybe I just didn't came across yet.

Anything that runs gtk-update-icon-cache will do a full global re-cache, so as long as it is run at least once since you install geany to a live system, it will be fine.

Again, the risk of not running it is that cache lookups think it doesn't exist. So, what constitutes a cache lookup? Well, it is built into gtk, you're not supposed to have to think about it. :) Basically any function Gtk offers for looking up icons for you by name rather than absolute filepath. See e.g. gtk_icon_* or gtk_image_*, glade GtkImage* stuff...

So the risk is when installing into a shared prefix where someone else already created the cache, like `/usr/local`? If the cache does not exist (e.g. when installing into a Geany-specific prefix) it'll be fine because GTK will do a full lookup, right?

Given that, and that autotools is still there and this generally does not affect packages (who set DESTDIR and must a find different solution anyway), I think I would go @eli-schwartz suggestion in https://github.com/geany/geany/pull/2761#issuecomment-1046137818 except perhaps printing the exact command that's needed. With time meson 0.57 will propagate to the systems. If that's not sufficient we can find a solution later on.

@kugel- pushed 1 commit.

d51f334e9bcb73ce9341f91bf68a2e1ca6d6111e Run gtk_update_icon_cache only on newer meson

Alright, unless anyone objects I will merge the the current state in a few days.

@kugel- pushed 1 commit.

c31892063a3eb27a47934422b8b7a0bd05e11575 use meson features

@kugel- pushed 3 commits.

c7bebb895ac425d9e0a8c15bdbf85a2548322a97 fixup! Prepare for meson build system 74e1d6d4cd247248fce417e8b25eea51b29c2b7d no config.h.meson 33ac301fe9ec732aff7ecaa4b0d332edc70e45e4 fix HAVE_DECL___ENVIRON and HAVE_DECL__NSGETENVIRON

@techee Can you please have a specific look at [33ac301](https://github.com/geany/geany/pull/2761/commits/33ac301fe9ec732aff7ecaa4b0d...) ? Is it OK to do it this way? My understanding of the comment is that the actual values of the defines is irrelevant.

I think so, yeah. I believe whatever compiles and makes unit tests pass is OK (I haven't tried yet though). Also the comment in configure.ac may be invalid now because something has changed in uctags in the meantime and these macros don't need to be defined any more.

@kugel- pushed 3 commits.

0dcea51e5d83a723f58d5506fc12f366bf6ae5bc Prepare for meson build system 831dc814e3542808c640a0acf0459b42907b7b5b Add build directories to gitignore d0575f5c908531027bd1c5fbedbcfe5a3802fff7 Port to the meson build system.

Complain :smile: There have been a number of changes since anyone but you tried it. You shouldn't do a Neil and only give one days notice for people to look at them and test.

Whilst in theory its safe since autotools should still work, this touches a number of the autotools files as well. Since it passes CI its ok on Ubuntu, leaving a couple of weekends for other distro users to test it and for it to be tested with plugins is sensible.

Just gave it a quick shot, with the same tests as last time: build and install Geany, build and install G-P against the previously built Geany and compare file system differences.

The complete boring results are in https://gist.github.com/eht16/673f850caf4d4989b3c3a53b6748d754.

It looks much better now: - the differences in installed Geany files between Autotools and Meson are much smaller - G-P compiles and installs

However, there are still issues: - G-P installs into `/tmp/meson-install/lib/geany` but Geany's plugins are installed to `/tmp/meson-install/lib/x86_64-linux-gnu/geany` and Geany also looks only in its path, i.e. we still have a problem with the `x86_64-linux-gnu` part - there are still file system differences: - `share/icons/hicolor/24x24/apps/geany.png` is installed by Meson but not by Autotools, might be fine but why? - `share/doc/geany/LexillaLicense.txt` is missing with Autotools but already known and Lex created an issue for it - `share/icons/Tango/icon-theme.cache` is missing with Meson but probably harmless - Meson adds the `x86_64-linux-gnu` in LIBDIR. Might be correct and fine but G-P should notice and use it then

From @elextr's comment above:

Correct, as @eli-schwartz said, on Debians and derivatives the "correct" place is the architecture specific directory `lib/x86_64-linux-gnu`, not in basic `lib`. I expect this is because Debian builds for x86_64 and also ARM and IBM and they need to be separated. So in this case the meson build is more correct than the autotools build and should stay as it is.

My comment which is being referred to:

The issue with `$prefix/lib/x86_64-linux-gnu` is because there's a Debian quirk. For both autotools and meson, the default if not specified is `--libdir=lib`, however, only with Meson that default changes on systems where dpkg is installed and the debian release file is found in /etc, to the directory output by `dpkg-architecture -qDEB_HOST_MULTIARCH`.

With autotools, the official debian package for geany instead just passes an option to `./configure --libdir='${prefix}/lib/x86_64-linux-gnu .....` because they really, really, really want all projects to use that directory.

The user specified value `--libdir=lib` will always override that. But apparently it's considered a bad idea on Debian.

Do you use this PR for the autotools build? The first commit of this PR extends the autotools build a bit (for example 24x24 geany.png and LexillaLicense.txt)

My autotools build was with current GIT master from Geany directly. Just tried again from the meson branch and then the file differences are related to the `x86_64-linux-gnu` infix. So it's all fine, great!

gtk theme cache requires very recent meson, see previous discussion.

I'm using Meson from Debian Testing: 0.61.2

The libdir story is really messy, will have a look.

I don't mind the final path at all. If it's all in `lib/x86_64-linux-gnu` this is probably fine. I just think, G-P with Autotools should then also use the same path, otherwise Geany won't find the installed plugins.

PS thank you to @kugel- for the persistence and effort of getting this far even if I kept throwing out the anchor from time to time :smile:

I mentioned earlier here, I always configure G-P only by poiting it to geany's pkg-config file, that selects prefix and libdir correctly in my experience.

`./configure PKG_CONFIG_PATH=/home/lex/geany-meson/lib/x86_64-linux-gnu/pkgconfig` or whatever that is on Ubuntu.