Ponderings on mutability of source builds and binary prebuilts
markfinal opened this issue · 4 comments
Recently, I've discovered that CMake's find_package is more limiting than I first thought.
It will only ever find binary prebuilts. Even if you've done an add_subdirectory for the sought package, and then a find_package (potentially in a thirdparty CMakeLists.txt), it will never detect that you've asked the package to build from source. Never. You have to modify each use of find_package to check if it wasn't found, etc.
BuildAMation is currently at the other end of the spectrum - every Module except those marked as [Prebuilt] are built from source. I definitely want the option to choose whether I can use a prebuilt if it's available.
And herein lies the problem. How can that happen?
I did have thoughts about an 'install' process that would then write a new BAM script for a binary built package. But then this is very disjoint from where the package is maintained.
I'd much rather have it so that a package's BAM scripts are mutable between prebuilts and source; either with the existence of binaries, or a flag to force source builds.
This seems difficult thought.
So I think there should be a configurable location where BAM prebuilts can reside. Along a similar mechanism for how there is a configurable source archive location.
However, standard locations for installs per OS (c:\program files, /usr/) should also be checkable I think.
Suddenly BAM is having to do a lot of the things that other build systems do too.
Normal build modules shouldn't need to be changed.
But the SDK work should be rolled in.
When you do a this.UseSDK(), the dependency chosen within should either be the prebuilt binary or a source build, depending on files on disk and options.
The calling code shouldn't care.
Is the logic to find binaries in UseSDK though, or per Module?
Feels like it should be something invoked from UseSDK, so it's generic, but finding binaries is a very Module specific thing. So sounds like something that's part of the SDK API, and must be implemented. But can probably be some helpers along the way.
An SDK Module needs to be able to identify the files on disk that form its SDK. I imagine there can be 4 states:
- fully resides on disk and meets all criteria (installed version match)
- fully resides on disk but does not meet all criteria (different version match)
- partially resides on disk (broken version)
- nothing resides on disk (not installed)
May not want to deal with all these, in case they are expensive? e.g. imagine the workflow in determining if a Boost or Qt implementation were complete. Could leave it to the compiler/linker to tell the user if something is broken.
Does it do this in script?
Or in a datafile?
At the very least, a version check is probably needed.
That will require some pattern matching in files.
You should not be able to distinguish a BAM built binary with one from another build system.
There should be a matter of preference on where to find them though.
BAM binary search paths first (as fresher builds, probably).
Then system search paths.