> […] the "all in" problem with GP currently where a plugin either has to > completely move their plugin into GP repository, thus loosing the ability to > have a separate Git host
That's not really true, you can just fine host your GP fork wherever you want. Of course if you want your changes to be integrated into the combined release, it has to be pushed back to the repository where this happens, but that's no different from anything else. > and even it's own (standalone) Autotools build system. That shouldn't be a problem: what's the advantage of own separate build system that we couldn't get in GP? You can configure a single plugin and leave the rest alone with `--disable-all-plugins --enable-yourplugin`. If that's not enough, we could probably make it even more friendly, I don't know, like `--enable-plugins=yourplugin` or something, whatever's convenient and not to hard to do. And most people suck at Autotools, so most people are generally happy whenever it works, not wanting to know anything else about it -- so not having to maintain it seem like a bonus rather :) > It's still a little annoying having to maintain separate Autotools files for > inside GP vs external, but it's not so bad (at least with Overview which is > trivial to build). Hum. I don't know how submodules work, but won't that often become a problem to maintain the separate build system? Maybe not really much more than currently, but currently it's all together so it's fairly obvious it has to be updated. But well, if submodules need to be updated manually, I gues sit's a matter of PRing properly the update. But it still duplicates work. > In a perfect world external plugins using Autotools themselves also could > just add `AC_CONFIG_SUBDIRS` and re-use their existing (sub) build system, > but I fear that would be more complicated, and I know it would be more slow. Well, that'd probably be nicer in theory for self-containment, 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. I'm not sure how easily this can be done, but I guess it would require to have a separate build system stub (well, possibly only Autoconf macros) that external plugins also use. So, really not trivial. But it would profit external plugins even not linked to GP. > I noticed Travis' Autotools doesn't support `AC_CONFIG_MACRO_DIRS`, but we > could do it other ways […] You can probably use `ACLOCAL_AMFLAGS = -Itherightdirectory` in *Makefile.am*, see https://www.gnu.org/software/automake/manual/autoconf.html#index-AC_005fCONFIG_005fMACRO_005fDIR-62 Also, I'm not sure it's possible to have several `AC_CONFIG_MACRO_DIRS` calls, so it wouldn't be a solution for several plugins anyway. --- 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-225364499
