Changes in liblwgeom do not trigger rebuild of postgis shared object

[strk]

Very annoyingly, it always take a make clean when you only change liblwgeom…

[mcayland]

Yeah. I've had an idea as to how to fix this by breaking the list of OBJs for liblwgeom into a separate include file that we can use in both Makefiles. But in the meantime, I normally do a "touch postgis/lwgeom_pg.c; make install" which works for me.

Mark.

[mcayland]

What do you think about the following patch?

[mcayland]

Actually - some more testing here with that patch shows that make combines the dependency information from an .o file with no actions with the PGXS build actions so that everything "just works"TM. This means I can get away with the attached revised v2 patch too.

[strk]

it's weird for .o files to depend on an .a file isn't it ? Shouldn't it be the final linked thing only ? This patch would rebuild all .o files which is unneeded, unless _headers_ from liblwgeom are changed.

[mcayland]

I think there are several different scenarios going on here, for example:

1) liblwgeom API/struct change → you want to rebuild everything 2) liblwgeom tinkering (e.g. adding extra LWDEBUG(F) statements) → you only want to rebuild one particular file

What you're suggesting would work for scenario 1) but not scenario 2) as there is no API change involved

[strk]

I'm suggesting to encode _more_ dependencies.

*.o files would depend on *.h files in liblwgeom libpostgis-<version>.<ext> would depend on liblwgeom.a

does it make sense ?

[mcayland]

So you mean break out the headers to one .h file per .c file? Sure that could work, but that's going to involve quite a bit more fiddling around and there are still edge cases where it wouldn't work (e.g. if a struct was declared in a .c rather than a .h file). Given the amount of work involved, I'm inclined just to stick with the v2 patch unless you want to do the extra refactoring?

[strk]

Not really. It's fine for a rule to rebuild _more_ than needed. Main problem here is building _less_ so as long as that's fixed I'm happy. I was just suggest to slightly reduce the unnecessary rebuilds but not as much as tracking individual .h files.

I say go ahead with your patch and we see how it goes. We'll always be able to file new tickets if we want to improve further. So we avoid getting stuck on details…

[mcayland]

Agreed - it's a starting point that we can always refine later, but at least it solves the main issue which is people forgetting to force-rebuild PostGIS when working with liblwgeom.

Committed to trunk at r7571 - I don't feel we should port this to 1.5 branch as it's a new behavour and people may have some objections to it. We could reconsider at a later date if everyone gets on with it though.