I got the first chance to try a new clean clone of git Geany for ages, and it still uses the toggle comment for all the config files, the changes in #3413 and #3428 don't seem to be happening, @techee and @b4n (committer) do they work for you with new clone at https://github.com/geany/geany/commit/b143e481ef472da1d49c8aabb3842ff20ba7b3...
Ok, problem solved, the machine I am using temporarily had another Geany installed, explicit executable path fixed this :-)
Closed #3451 as completed.
Ok, problem solved, the machine I am using temporarily had another Geany installed, explicit executable path fixed this :-)
I remember having this problem when switching between meson build and autotools build - each of them installs `geany.so` to a different location - autotools to `/usr/local/lib` and meson to `/usr/local/lib/aarch64-linux-gnu` and I think the latter one takes precedence. If there were a way to unify this behavior, it would be great to avoid similar problems.
Back to the reported problem, another possibility could have been that you had some old config files in the config directory which contained the `#~` - these legacy config files will stay as they are.
I remember having this problem when switching between meson build and autotools build - each of them installs geany.so to a different location - autotools to /usr/local/lib and meson to /usr/local/lib/aarch64-linux-gnu and I think the latter one takes precedence. If there were a way to unify this behavior, it would be great to avoid similar problems.
It would be good to fix it. IMO (at least on my Mint machine) meson used the right place, and autotools used the wrong one. Geany was the only thing in the location autotools chose, but meson chose the same place as all the other stuff installed by the distro. But don't like our chances of "fixing" autotools except by deletion :stuck_out_tongue_winking_eye:
But my problem was simpler than that, I just didn't know that an old system install of Geany was earlier in PATH, so was running the wrong version, so old behaviour happened.
Back to the reported problem, another possibility could have been that you had some old config files in the config directory which contained the #~ - these legacy config files will stay as they are.
It wasn't my problem as I used `-c /tmp/config` so it was clean, but yes, not worth changing such files, if a user has edited it better to not touch it.
It would be good to fix it. IMO (at least on my Mint machine) meson used the right place, and autotools used the wrong one. Geany was the only thing in the location autotools chose, but meson chose the same place as all the other stuff installed by the distro.
It's IMO a **serious** issue with the Meson setup if it install by default in */usr* rather than */usr/local*. I certainly don't want manually built software to clutter */usr* by default, and I expect doing so to cause a whole new sets of issues even if it "fixes" some case by overriding an existing installation (which is wrong if that install is managed by the package manager).
So *please*, don't try to "fix" Autotools to that regard, it's actually doing the right thing. As for the arch triplet, indeed it might not be the right thing **but** */usr/local* might have different rules, and any sane distro has the proper setup for Autotools to select the right location (remember they are likely to actually *use* Autotools to build a significant portion of their archive) -- and certainly I never saw a distro failing here, but Ubuntu to some extend (remember the ldconfig shenanigans we have because they messed up their LD configuration). So if it's not right, let the distro fix it: they can, and they should be the one deciding -- if *you* don't like it, manually set each specific path with the relevant switch.
It's IMO a serious issue with the Autotools setup if it install by default in` $prefix/lib` rather than `$prefix/lib/x86_64-linux-gnu` (or `i386-linux-gnu` or `aarch64` or whatever as appropriate). I certainly don't want manually built software to clutter `$prefix/lib` by default, and I expect doing so to cause a whole new sets of issues even if it "fixes" some case by overriding an existing installation (which is wrong if that install is managed by the package manager).
So please, try to "fix" Autotools to that regard, it's actually doing the wrong thing.
[PS thanks for writing the above, I just corrected a few things ;-P)
Essentially Autotools has not caught up with mixed architecture distros, or Geany's use is constraining it incorrectly.
And since the distro pkg-config looks in `$prefix/lib/x86_64-linux-gnu/pkgconfig` the Geany install in $prefix/lib/pkgconfig might not be found (its empty here, so don't know).
Note that the system Geany that caught me out above is installed in `$prefix/lib/x86_64-linux-gnu`, the only files in `$prefix/lib` are `nvidia-gtk3*` and `mono*` files, poster children for fitting into Linux, 'nuf said :grin:.
It's IMO a serious issue with the Meson setup if it install by default in /usr rather than /usr/local
I think this is not what @elextr meant - he meant that when using autotools, it places things directly under `/user/local` and not under the architecture-based subdirectory.
I had a look at what Meson does and it seems to be a very Debian-specific thing:
https://github.com/mesonbuild/meson/blob/439a61affab391d44341ac3113592698abd...
github-comments@lists.geany.org