search

StrawberryPerl / build-extlibs

16 stars 11 forks source link

Reuse existing build artefacts where available #17

Closed shawnlaffan closed 1 year ago

shawnlaffan commented 1 year ago

This will save substantial development time as long-running build processes can avoid rebuilding dependencies.

shawnlaffan commented 1 year ago

One limitation of the approach in this script is where a package early in the chain (pk1) is rebuilt but the intermediate ones are not, and where the intermediate packages change behaviour based on the version of pk1.

e.g. given the dependency chain pk1 -> pk2 -> pk3 -> pk4, where pk2 changes properties when compiled against a more recent version of pk1. If the build script is told to rebuild pk1 as part of a build for pk4 then this script will grab the build artefacts for pk2 and pk3.

In this case the source file can be updated to add rebuild flags to each package but that gets messy for non-simple dependency chains as people running the script need to know what the dependencies are. It is probably simpler to add an env var to force a rebuild of all target packages.

In a perfect world there would be dependency tree for all the packages but that's a separate issue, perhaps on the wishlist end of the spectrum. (Such a tree could be cribbed from the MSYS2 packaging system).

shawnlaffan commented 1 year ago

The script name also needs work as it could be interpreted as a post-processing step.

Perhaps something like 'filter_source_list_and_reuse_build_artefacts' which is informative but perhaps too long, although it is only for use from the build script.

genio commented 1 year ago

I think I'm good with the name as-is. From what I see, this is ready to be merged. Do you have anything else you wanted to fix up before I do so?

shawnlaffan commented 1 year ago

Thanks.

I have no more commits for this PR.

shawnlaffan commented 1 year ago

Although one potential issue is with non-standard DLL suffixes. The packaged files in the _out dir do not include the suffix in their names so if a build is run using a suffix of __ and then a second is run using xx then the second will have a mix of suffixes.

How much this matters depends on how flexible this system needs to be. It could just require a doc update to note that all builds in a container should use a consistent suffix for a given bitness.