External plugins #440
External plugins #440
Conversation
To be replaced by submodule.
When using $(top_srcdir) or even $(srcdir), config.status or something else in Autotools tries to put the files in a literal '$(top_srcdir)' directory it creates, which causes it to blow up because it ends up putting the .deps stuff somewhere it can't find. TODO: find out why this happens and fix it
|
I noticed Travis' Autotools doesn't support |
|
It'S a good idea. How would it work with documentation? Maybe also a good point to rework documentation of the g-p project at all to have all on same level of quality. |
|
I'd definitely support anything that improves the current situation with external plugins. From the patch maybe I'd just prefer if the README's and friends that got moved to build/overview stayed more together with the plugin in the overview directory. Couldn't they just stay where they are and couldn't the subrepo live in a subdirectory of overview? |
|
@frlan not sure about what to do for documentation. If you look at overview it has a pretty nice README file which renders correctly on Github and whatnot. I never adapted it for GP because I hate restructured text, it won't render on Github without correct extension, and I didn't want to maintain separate documentation. We could probably do something like we do now for docs, but having the script look in the submodule for a README.whatever file, use it if available, and if not, see if there's one in the GP build system files. |
|
@techee yeah that would work too, I just put the build system files (and files it strictly requires like ChangeLog NEWS README etc) off into the existing directory for build system stuff. I think it would be nicer/cleaner not to have so much nested directories as we would if each submodule was a subdir in a subdir. |
Yeah, makes sense. It would just be nice to have all the files related to a plugin in a single directory - it's easy to forget something needs an update when it's located at a completely different place. I don't know how exactly submodules work but wouldn't it be possible to have a separate subdirectory for the geany-extra files within the submodule tree and .gitignore it in the submodule? For the submodule it should work but I'm not sure if it doesn't get then ignored also for GP which is something we don't want. Anyway, IMO your current approach looks just fine and there's always the possibility to improve it in the future. |
I'd suggest doing it separately from this patch as the documentation thing looks like a much more work and would unnecessarily delay the merge of this patch. |
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.
That shouldn't be a problem: what's the advantage of own separate build system that we couldn't get in GP? 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 :)
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.
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. So, really not trivial. But it would profit external plugins even not linked to GP.
You can probably use |
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.
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.
Thats why special options like
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.
Is there really that much it would need to re-implement? Maybe some gettext stuff, possibly something like
IIUC @sardemff7 tried it and it still had the issue I experienced.
It takes multiple space-separated directories, presumably equivalent to multiple |
We could also distribute a separate geany-plugins.m4 file that provides external plugins choosing to use Autotools with a convenience M4 function library. |
Well in GP itself, all the files to be updated would be in a single subdir, like
I don't think it's possible to .gitignore stuff in the submodule and not in the parent repo since .gitignore is always read and is recursive. Moreover, it imposes requirements on upstream, which may or may not have the same GP maintainer as upstream (see GeanyPy, until recently). That said, I don't think it's unreasonable to push some boilerplate build stuff (which doesn't conflict with own build system) to the external plugin, to "register" itself with GP's build system. |
This is probably important, there needs to be a way to avoid translators having to make patches on 50 different repos in order to get translations in GP (edit: and still allow external plugins to have gettext translations if they use gettext, ideally). This reverses the dependency order back to opposite of what the PR tries to achieve. Any ideas? |
|
i18n: you can have a central translation catalogue over more than one catalogue. Gnome is doing it. But this will need some extra toolchain Documentation: Have a look onto all the README and other documentations of plugins. plugins.geany.org is a dirty hack to get them somehow clued together but you can use the page to see huge difference in quality and verbosity of documentation at all. In addition a huge amount is just the because it's copied pasted. I doubt having g-p being a project just based on submodules will improve this if we don't activate change it. Please don't think as technicians hacking autotools stuff (there is a reason autotools is hated by everyone not infected by the Stockholm syndrom and there are so many attempts to make it better). Think about a user downloading the plugins and wants to get info how it works. Right now, I don't understand some plugins and how they should work even when I read code and I understand what they are doing on Scintilla level. IMHO we did to much fire and forget for convenience last years in general. I really don't care to have documentation splitted into another repo, because it can a sub module too on users as well as on developers site. |
This PR isn't meant to be merged.
I made it to show how we could allow "external" plugins, keeping their proper repositories as submodules to avoid 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, repository history, and even it's own (standalone) Autotools build system.
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). In a perfect world external plugins using Autotools themselves also could just add
AC_CONFIG_SUBDIRSand re-use their existing (sub) build system, but I fear that would be more complicated, and I know it would be more slow.Any thoughts?