Am 1. Dezember 2015 02:19:10 MEZ, schrieb Matthew Brush <notifications(a)github.com>:
>> depenencies are globally known to make; for G-P this means that
>plugins don't need to be build in a specific order, but simply as soon
>as possible
>
>Is that really a thing even for GP? I have not much clue about how Make
>works, but it seems like since none of the plugins depend on each
>other, they can all already be parallelized and not build in a
>particular order. Is it a Make-ism why this isn't the case?
>
>---
>Reply to this email directly or view it on GitHub:
>https://github.com/geany/geany-plugins/pull/277#issuecomment-160816125
The default recursive automake setup which GP uses prevents this. This is exactly the purpose of this PR, enabling full parallel build.
Recursive automake processes SUBDIRS in a for loop which can't be done in parallel. This PR does away with SUBDIRSand instead creates proper make targets with complete dependencies. Then the recipes can be build in parallel.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/277#issuecomment-160866530
> depenencies are globally known to make; for G-P this means that plugins don't need to be build in a specific order, but simply as soon as possible
Is that really a thing even for GP? I have not much clue about how Make works, but it seems like since none of the plugins depend on each other, they can all already be parallelized and not build in a particular order. Is it a Make-ism why this isn't the case?
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/277#issuecomment-160816125
>* full conversion (don't leave a third-or-so of the plugins recursive)
...
>
>However, while I do like the technical advantage of the result (faster,
>parallelized builds from the bottom-up, less Make overhead, etc…), I
>don't really like the changes this PR makes. It adds duplication on
>stuff that was nicely generic (i.e. `plugindoc` stuff) and has some
>subtle gotchas in the recursive vs. non-recursive versions
>(`SHORTNAME`, conditionals, custom targets, etc.).
>So in the end, I'm really not sure I like the changes, as I find the
>benefits not enough for the (current) added complexity.
So this is why I haven't converted all plugins yet. Merging is far from guaranteed. So I would like to get a decision based the current conversion with all other remarks fixed.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/277#issuecomment-160717018
> - ao_wrapwords.h \
> - ao_copyfilepath.h \
> - addons.c \
> - ao_blanklines.c \
> - ao_doclist.c \
> - ao_openuri.c \
> - ao_systray.c \
> - ao_bookmarklist.c \
> - ao_markword.c \
> - ao_tasks.c \
> - ao_xmltagging.c \
> - ao_wrapwords.c \
> - ao_copyfilepath.c
> -
> -addons_la_LIBADD = $(COMMONLIBS)
> -
> include $(top_srcdir)/build/cppcheck.mk
No, I mean that `make check` (from the top-level) should have the same behavior as running `make check` from each sub-directory. As *build/cppcheck.mk* adds rules to be executed upon `make check`, and that this is only included in the recursive Makefile, these checks will only be run when running `make check` from the sub-directories and never from the top-level.
Before these changes, `make check` was recursive (like most common targets, like *all*), and so running it from the top-level ran checks in the whole tree. Now, `cppcheck` checks are missing from all plugins you converted to non-recursiveness when invoked non-recursively.
You can probably understand quite easily by giving a look at *build/cppcheck.mk*, knowing that `check-local` is a dependency of the `check` target.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/277/files#r46167175
At the very least this has to be fixed/corrected:
* leftovers
* fix *cppcheck* support
* full conversion (don't leave a third-or-so of the plugins recursive) (I know this is known, just want to point out to @frlan)
* documentation update (*HACKING*)
However, while I do like the technical advantage of the result (faster, parallelized builds from the bottom-up, less Make overhead, etc…), I don't really like the changes this PR makes. It adds duplication on stuff that was nicely generic (i.e. `plugindoc` stuff) and has some subtle gotchas in the recursive vs. non-recursive versions (`SHORTNAME`, conditionals, custom targets, etc.).
So in the end, I'm really not sure I like the changes, as I find the benefits not enough for the (current) added complexity.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/277#issuecomment-160662572
Should check with @techee, I think OSX has super old-timey Automake, though likely a newer version can be built/installed using one of the package managers available for OSX.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/277#issuecomment-160661994