Less recursive Autotools

[b4n]

_Do NOT merge this_ yet. This at least doesn't port all plugins.

---

I wanted to use the subdir-objects Automake option in the GP build system, because some plugins build sources in sub-directories (debugger, scope, and geanyvc and geanyprj in their unit tests), and because it seems to be the future of Automake (e.g. someday it'll be impossible not to use it). Also, it's pretty neat (in theory).

The problem is that it has a bug when a subdir object is in a directory that also builds objects. This is problematic for us in the case of geanyprj and geanyvc usage.

Now, there are three options:

1. don't use subdir-objects, and deal with it the day it becomes unavoidable (maybe hoping the aforementioned bug gets fixed by then).
2. don't build the subdir objects in a directory that already builds objects. This basically mean we have to #include "../src/utils.c" in geanyprj and geanyvc unit tests -- not the worst thing ever in a unit test, but not the best either.
3. build all the objects in a particular directory from the same Makefile -- in practice, make things less recursive.

This PR gives a shot at option 3, and basically merges each plugin's Makefile.am-s together in [plugin]/Makefile.am. This leans towards the "non-recursive Automake" pattern some people advertize.

Pros I can think of:

• Works around the aforementioned Automake bug so allows us to use subdir-objects -- but that's not so important.
• Less recursion is supposed to be a little faster.
• All rules for a particular plugin (source, data, docs, …) are in the same place: more concise, provides an overview and ease modifications that touch several aspects at once.

Cons:

• All rules for a particular plugin (source, data, docs, …) are in the same place: more bloated and not split by aspect.

Of course, to simply allow us to use subdir-objects, only geanyprj and geanyvc build systems have to be tuned, but consistency over GP is good.

Enough chattering, let's see: what do you guys thing about this? Does what this PR start look like a good path to you or do you think it's a bad idea? @sardemff7 @hyperair @frlan @codebrainz @ntrel @elextr?

[elextr]

As we all know recursive make is evil http://aegis.sourceforge.net/auug97.pdf so less recursion is good :)

As for the details, tl;dr and don't know enuf autotools anyway :)

[sardemff7]

You are saying:

• All rules for a particular plugin (source, data, docs, …) are in the same place: more bloated and not split by aspect.

This does not have to be that way at all, although I do not see that as a problem since plugins are supposed to be simple enough.

Your changes are good from what I managed to see (big changes are always hard to review). But I would change that stuff even further. Non-recursive build at all (e.g. only one Makefile).

Depending on the Automake version you want to target, you could make it easy to split each plugin in its own project (with a minimal configure.ac and Makefile.am for each one) or just assume they all belong to geany-plugin and that it does not matter. (The required feature is %reldir%, so Automake 1.14.)

The idea is to include .mk files from each plugin (each one could include other files to make it perfectly split if you really want to).
In the Geany repository, there would be an .m4 file to define some basic rules, which would also print a nice summary all by itself. The base Makefile.am would define some variables that plugins would only add their stuff to. Then you can either conditional-include the .mk file or conditional-append the plugin’s stuff to the relevant variable.

You can see a working infrastructure in my j4status and j4status-plugins projects. (You need to git clone --recursive on these ones. If you do not manage to build them, I will gladly accept a bug report.)

[b4n]

• All rules for a particular plugin (source, data, docs, …) are in the same place: more bloated and not split by aspect.

This does not have to be that way at all, although I do not see that as a problem since plugins are supposed to be simple enough.

Indeed, it could be split in several .mk or otherwise. And I also agree that with the low complexity of each plugin's Makefile.am having everything together is likely to be better than worse. Currently most plugins actually have only one "interesting" Makefile.am in src/ and the one at the plugin's root only chains up.

Depending on the Automake version you want to target, you could make it easy to split each plugin in its own project (with a minimal configure.ac and Makefile.am for each one) or just assume they all belong to geany-plugin and that it does not matter. (The required feature is %reldir%, so Automake 1.14.)

While it would probably be nice, I don't see this as the most important step. Also, the complexity added by each configure.ac would probably annoy people more than they would appreciate the possibility of not using the global build system -- and also would make the thing slightly less easy to maintain. Disclaimer: I never tried this so may remarks may be completely off.
Also, depending on 1.14 seems a bit premature to me -- but IIUC the only need for %reldir% is to be absolutely non-recursive, so it would work with older AM with what my PR proposes.

Your changes are good from what I managed to see (big changes are always hard to review). But I would change that stuff even further. Non-recursive build at all (e.g. only one Makefile).
[…]
The idea is to include .mk files from each plugin (each one could include other files to make it perfectly split if you really want to).
In the Geany repository, there would be an .m4 file to define some basic rules, which would also print a nice summary all by itself. The base Makefile.am would define some variables that plugins would only add their stuff to. Then you can either conditional-include the .mk file or conditional-append the plugin’s stuff to the relevant variable.

While I like the idea in theory, I'm not so fond of having either the .mk at the root (looks less well-organized to me) or using paths not relative to the .mk location (looks trickier to me, and I wouldn't be surprised if some people had a hard time wrapping their head around it).

Also, how easy would it be to build and install a particular plugin? I think that it should be real easy because I would think most developers don't necessarily want to bother building anything but their plugin, while not wanting to bother about --disable-[plugin] (or even they might want to still have some other plugins built and installed because they use them). The current support of simply running make in the plugin's build directory seems real handy to me.

Anyway, those are just concerns I have, but I'm not at all against a real single-Makefile solution, rather the contrary.

[sardemff7]

Your PR seems fine as-is, considering what it aims to do.

To go a bit further on the full non-recursive approach:

It is quite easy to allow one to do a simple make in a plugin directory to build this one only, even with a full non-recursive setup. Here is the needed Makefile:

all: 
    make -C .. plugin/plugin.la

clean:
    make -C .. clean

Also, making a plugin a self-contained project would require a really basic configure.ac and Makefile.am setup. They would mostly be includes actually.

The relative path in subdir .mk files is solved by… %reldir%, but I understand why one would not want to depend on Automake 1.14.

[b4n]

Your PR seems fine as-is, considering what it aims to do.

OK, thanks for giving it a look :)
I may finish it and merge it as at least a first step, unless we plan on doing something more relatively soon.

It is quite easy to allow one to do a simple make in a plugin directory to build this one only, even with a full non-recursive setup. Here is the needed Makefile: […]

Indeed, building the plugin is easy as we have a special target, but what about specific installation and clean? Those are indeed less important (though clean might be nice not to have to rebuild everything after) but might still be wanted.
Though you're right that chaining from all to the plugin-specific target solves the most important problem (similarly as we could have SUBDIRS=.. Makefile.ams in the various sub-directories if we wanted to still be able to run make form any directory).

Also, making a plugin a self-contained project would require a really basic configure.ac and Makefile.am setup. They would mostly be includes actually.

Well, wouldn't we need to still basically copy the root configure.ac? (minus the whole plugins list)
We could indeed "upstream" to Geany the most common checks (e.g. geany.m4 and possibly gtk.m4), but wouldn't still be like 40 lines long? Ah, and we'd also have to split up the internationalization setup, not sure how (but that's probably also doable).

---

BTW, the "less" recursive approach in this PR probably won't help much regarding parallelism, as it still uses one subdir per plugin (unless there is a way to tell Make that it can recurse in several directories at once as ours are completely separated -- are they?), so if more parallelism is something we want to aim here, full non-recursiveness might be needed.

[codebrainz]

On 14-10-16 02:19 AM, Quentin Glidic wrote:

[snip]
Depending on the Automake version you want to target, you could make it easy to split each plugin in its own project (with a minimal configure.ac and Makefile.am for each one) or just assume they all belong to geany-plugin and that it does not matter. (The required feature is %reldir%, so Automake 1.14.)

It would be super useful to allow "standalone"-ish Autotools to be used
in GP. I thought about doing this the obvious way before (nesting
Autoconf subpackages) but it would make the configure+build process
unbearably slow when building multiple/all plugins.

Is there any way to make it where you could support completely
standalone plugin with typical ./configure && make but also have
something like this:

git clone <geany-plugins repo>
cd geany-plugins
git clone <plugin's repo> myplugin
./configure && make # all of GP and myplugin

and to have GP's build system detect that you just added a plugin
subdirectory to it and automatically make it part of the build system?

It's kind of like LLVM/Clang's build system where you can add different
"tools" directories and it picks them up and builds automatically,
except you'd also be able to build them individually as well.

Maybe I'm dreaming :)

[frlan]

At least I cannot say that I dislike the git submodule idea ... autotools I cannot add much, as it's still some cryptic globish to me.

[kugel-]

#277 implements an IMO superior solution to less recursive automake (using %reldir% as mentioned here before, e.g. in #164 (comment))

[kugel-]

@b4n are you still working on this?

[b4n]

@kugel- Not now, but I wish. Actually I'm not working on much Geany/GP stuff these days :(

[frlan]

@b4n What we are going to do with this WiP-PR?