-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Internal libraries are ignored #13
Comments
I think about it. Also several users, which build GDAL in Windows, point on this. But behaviour you mentioned have several problems:
Maybe worth adding some preset for Windows builds at the beginning of the root CMakeLists.txt with this options? And for such typical build the command may looks like:
|
Shortly, typical GDAL build with CMake on any platform should be this:
That's it, nothing more required. |
Agreed with simplification. Will do it.
it will be no matter where internal libraries sources get (from one repository or more). And this is more close how maven or gradle works for java. |
I was/am not aware of borsch principles. I take the CMake for GDAL as generic configuration, independent from any thirdparty platform, any package managers (conan.io, vcpkg, maven, etc.). I thought, CMake for GDAL is supposed to be drop-in replacement/alternative for NMAKE/Automake makefiles.
I assume, such issue is external to CMake for GDAL.
See my answer to 1.
Yes, it is, but
Besides, I haven't heard of any plans to get rid of maintaining internal libraries. Here we would have to ask @rouault to confirm any such plans.
I sense, CMake for GDAL tries to do too many things at ones. In other words, let borsch call CMake for GDAL should be completely generic and independent from tools and ideas of Borcsh or any packageing system. CMake for GDAL should be plain CMake scripts which build GDAL and, optionally, allows users to tell CMake where some of the non-default more advanced dependencies are located (like Please, don't get me wrong. I'm not saying nextgis-borsch does anything wrong. It does whatever it needs to do for nextgis-borsch. I just tried it out thinking/assuming it is generic CMake for GDAL configuration. It turns out it is not. It is "CMake for GDAL in Borsch". It works for you, no doubt, but it is not what general public of CMake & GDAL users expect. My 2 cents |
I just came to the project after the fact, but for me, those internal libraries are mostly for convenience of Windows users, for which no standardized installation tree exist. The incompatibility argument is not so true, since we allow also build against external libraries, which can be of different versions. |
@rouault Do you plan to get rid of the internal libraries? |
I would be -0 on this |
@rouault OK @BishopGIS I expected different approach of CMake for GDAL. Depending on concepts of any packaging system in CMake configuration is no-go for me and, IMO, no fit for GDAL. But, I don't want to impose anything to your approach. I'll rather close the issue. |
@mloskot the CMake for GDAL project began as your expected, but than transformed to something more different, as you say It is "CMake for GDAL in Borsch". This is result of user needs for build with different configurations and options, mainly for Windows users which used to select some checkboxes in CMake GUI and all dependencies magically solved :).
This is good idea (#14). |
@BishopGIS Yes, understood. Thanks for all the clarifications and the effort towards simplifications. I will try to help testing it. |
CMakeLists.txt seems to require all GDAL dependencies as external libraries.
For example, if json-c, zlib, libtiff, etc. are missing, CMake terminates with failure.
That is not how, for instance, NMAKE build configuration works: even if no additional libraries are specified/enabled in
nmake.opt
, commandnmake /f makefile.vc
completes build with success. GDAL will include not features for which external deps are missing though.IMO, CMake configuration should offer the same approach:
and even if I have no deps installed, I should expect to be able to build GDAL, with some fetures, no?
The text was updated successfully, but these errors were encountered: