#937 closed defect (invalid)
geos/.h files not available in framework Headers
Reported by: | xzcvczx | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Build/Install (cmake) | Version: | 3.6.2 |
Severity: | Unassigned | Keywords: | |
Cc: |
Description
If you build geos as a framework then and -Ipath/to/GEOS.framework/Headers you can't use <geos/export.h> for example as there is no geos folder in headers.
as all the files are in the root of headers this can easily be worked around by creating a symlink named geos to the Headers directory,
Change History (9)
comment:2 by , 6 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Actually, the way framework headers work, including <geos/whatever.h> works without using any -I flags. The build system tries frameworks that match the first part of the path in the <>. So, it knows that <geos/whatever.h> is the GEOS framework (names are not case sensitive) and look for the "whatever.h" file in the framework's Headers folder. Using a -I flag should not interfere with this.
And, there already is a symlink if really needed for some reason. It's in the "unix" folder, along with other standard unix-style folders, bin, include and lib. This simulates a unix style build, with the geos-config bin, and c and c++ library names.
comment:4 by , 6 years ago
I'm all confused are we talking about
https://git.osgeo.org/gitea/geos/geos/pulls/58
Which hasn't been committed yet? or https://git.osgeo.org/gitea/geos/geos/pulls/57 which has been committed. If it's 58, I can just close that pull request unmerged
comment:5 by , 6 years ago
Yes, 58. Huh, when I browsed the source, I saw it applied.
https://trac.osgeo.org/geos/browser/git/src/CMakeLists.txt
Change:
https://trac.osgeo.org/geos/changeset/f0b08d802543cbde75a09ccb0b4e94ec40da0707/git
comment:6 by , 6 years ago
Hmm I wonder if it's some configuration in trac that it's showing the latest fork/branch commit and not what is in the master branch
Line 56 from master repo reads this:
https://git.osgeo.org/gitea/geos/geos/src/branch/master/src/CMakeLists.txt#L56
install(CODE "execute_process(COMMAND ln -sfh ../../Headers \"${GEOS_FWDIR_VER}/unix/include/geos\")")
and not what is in pull request and https://trac.osgeo.org/geos/browser/git/src/CMakeLists.txt
install(CODE "execute_process(COMMAND ln -sf . \"${GEOS_FWDIR_VER}/Headers/geos\")")
comment:7 by , 6 years ago
One more note: the "unix" folder is created when the GEOS_ENABLE_MACOSX_FRAMEWORK_UNIXCOMPAT option is used.
comment:8 by , 6 years ago
i will claim to blame proj here, as it seems that iframework needs the <framework/.h> otherwise it doesn't descend into the Framework and headers as far as i can tell, if you know something which will make it work without explicit -I/-isystem into Headers or unix feel free to correct me
comment:9 by , 6 years ago
different frameworks in the GDAL stack have different behaviors for how headers are expected to be included. Some have a subfolder, so they work as framework includes, like GEOS. Some do not have a subfolder, so they need a -I flag, like PROJ.
It's OK to always use -I on the Headers folder, it doesn't interfere with framework includes. This is more portable to other systems. And even if you are writing Mac-only software, it's safer because you may have external sources that expect unix-style includes.
Pull Request 58