vyasr commented on issue #875: URL: https://github.com/apache/arrow-nanoarrow/issues/875#issuecomment-4271209347
Thanks Dewey! And hi 😃 The justification for this change is that say I build my nanoarrow package with `BUILD_SHARED_LIBS=OFF` so I produce a static llibrary. Then, I install that into some environment where I then try to build my own package foo as a dynamic library with `BUILD_SHARED_LIBS=ON`. With the current approach, what will happen is that the [nanoarrow config will make `nanoarrow::nanoarrow` an alias for `nanoarrow::nanoarrow_shared`](https://github.com/apache/arrow-nanoarrow/blob/3306ac6e884392c8f7303d9dd3355af546276b65/cmake/config.cmake.in#L29), which will then fail right after configuring because the `libnanoarrow.so` library that `nanoarrow_shared` references doesn't exist. That error will look something like ``` ninja: error: '... libnanoarrow_shared.so', needed by libfoo.so, missing and no known rule to make it ``` Note that `libnanoarrow_shared.so` isn't even the real library name, it shows up because if CMake doesn't have a real library associated with the `nanoarrow_shared` target that name winds up being passed to the underlying compiler command as a raw `-l ${target}` argument. With the proposed change, `nanoarrow::nanoarrow` will correct reference the `nanoarrow.a` archive that was actually built into the nanoarrow package at build time. If the consumer actually has a hard requirement for either the shared or static library, then they can request the `nanoarrow::nanoarrow_shared` or `nanoarrow::nanoarrow_static`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
