<div dir="ltr"><div dir="ltr">(on-list)<div><br></div><div><div>Hi,</div><br><div class="gmail_quote"><span class="gmail-im" style="color:rgb(80,0,80)"><div dir="ltr" class="gmail_attr">On Tue, 5 Oct 2021 at 14:16, Javier Jimenez Shaw <<a href="mailto:j1@jimenezshaw.com" target="_blank">j1@jimenezshaw.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>How would CMake behave with all those options that are defined depending on what is present on the compiler machine?</div></div></blockquote><div> </div></span><div>This is orthogonal to CMake vs Make, but the RFC does discuss cleaning up consistency of build options cross-platform and the opt-in/out of building drivers.</div><div><br></div><div>In general, for most people building I think we want the build to automatically pick up the libraries/formats/options that are available so it works for them with minimal effort. But we should set it up, as Kurt mentioned, for builders to easily be able to "opt-out" of (nearly) every driver and then selectively re-enable them (& obviously their dependency requirements) as needed.<br></div><div><br></div><div>Different distributions have different approaches here — some build with basically every possible option & dependency enabled ("the kitchen sink"), others build with limited dependencies and as a user if you want to turn on anything else then you'll need to rebuild it yourself.</div><span class="gmail-im" style="color:rgb(80,0,80)"><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>IMHO, the libraries included should be independent on what is already installed on the compiler machine. The last time something/somebody included "zstd" in our compiler machine, and not in the executing machine, and we couldn't run anything. We did not need zstd, but it was there, breaking the execution. I know that the solution there is disable it "--without-zstd". What I do not like is the lack of definition, because what is present on the compiler machine may change.</div></div></blockquote><div><br></div></div></span><div>If you are packaging for distribution (within an org or publicly), being careful about which dependencies/versions/etc are available is a regular issue which projects like GDAL shouldn't try to overly control — everything needs to be built in an isolated environment, be it a container, fakeroot/chroot, or something else. Downstream packagers for Linux/BSD/etc all are very careful to do this, it's not a new problem.<br></div><div><br></div><div>Rob :-)</div></div></div></div></div>