> That's not really true, you can just fine host your GP fork wherever you > want.
With a fork of GP, you carry along all the extra files and git history and Github Issues and stuff of plugins you don't care about. > what's the advantage of own separate build system that we couldn't get in GP Ability to use own (non-Autotools) build system, or to use non-recursive automake, or just to have a much simpler and light weight Autotools build system. > And most people suck at Autotools Thats why special options like `--disable-all` in combination with `--enable-foo=yes` aren't ideal if a plugin wants a standalone distribution. > But it still duplicates work It does, but it separates it too. GP requires special autoconf macros and boilerplate files and stuff, so it's not a huge deal having a separate non-GP specific (potentially Autotools) build system, IMO. The redundant boilerplate in GP becomes just like the boilerplate/metadata needed to put packages in a package manager, just a way to get an external plugin distributed with geany-plugins. > but currently any external plugin that want to do things right have to > re-implement a lot of GP's build system checks and features Is there really that much it would need to re-implement? Maybe some gettext stuff, possibly something like `--with-geany-libdir` and own check like `PKG_CHECK_MODULES([GEANY],[geany])`? > You can probably use ACLOCAL_AMFLAGS = -Itherightdirectory in Makefile.am IIUC @sardemff7 tried it and it still had the issue I experienced. > I'm not sure it's possible to have several AC_CONFIG_MACRO_DIRS calls It takes multiple space-separated directories, presumably equivalent to multiple `AC_CONFIG_MACRO_DIR` calls, which is probably not valid. I think it requires new-ish Automake though. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany-plugins/pull/440#issuecomment-225371983
