Opened 8 years ago
Closed 7 years ago
#3091 closed defect (fixed)
The RUN_GISBASE variable is not set correctly on FreeBSD
Reported by: | pieside | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.2.2 |
Component: | Default | Version: | 7.0.4 |
Keywords: | FreeBSD | Cc: | |
CPU: | x86-64 | Platform: | Other Unix |
Description
I'm trying to port Grass7 in the ports tree to make the installation easier on FreeBSD.
The include/Make/Platform.make file contains the RUN_GISBASE variable with the following value:
dist.amd64.portbld-freebsd11.0
The compilation search the includes files (e.g., gis.h) in this directory. But it is empty. All the includes are located in another directory:
dist.amd64
Why is the first directory empty?
This thread https://forums.freebsd.org/threads/56766/#post-323057 suggests the Makefile contains rules to create those directories. I presume the solution lives somewhere in a file in the include/Make/ directory but I can't figure it out
Attachments (1)
Change History (7)
by , 8 years ago
Attachment: | Platform.make added |
---|
comment:1 by , 8 years ago
follow-up: 3 comment:2 by , 8 years ago
After some tests, I found that the issue is probably coming from the ports tree framework which overrides the value of ARCH. This seems to comfort that the issue may be with the build system.
To avoid duplicate and because it seems to be FreeBSD specific, I continue the discussion here: https://forums.freebsd.org/threads/56766/#post-323073
comment:3 by , 8 years ago
Replying to pieside:
After some tests, I found that the issue is probably coming from the ports tree framework which overrides the value of ARCH. This seems to comfort that the issue may be with the build system.
Setting ARCH= on the make command line will override the setting of ARCH in Platform.make.
Ideally, that should work; i.e. you should be able to set ARCH to whatever you feel like and everything should use that setting consistently. But it doesn't, because configure.in does:
AC_SUBST(ARCH) ... GISBASE="${WINDSTDIR}/dist.${ARCH}" GRASS_BIN="${DSTDIR}/bin.${ARCH}" AC_SUBST(GISBASE) AC_SUBST(GRASS_BIN)
So the value of ARCH chosen by the configure script gets used to set 3 distinct variables, and overriding ARCH on the command line only changes one of them (although GRASS_BIN isn't actually used).
GISBASE is actually used to set RUN_GISBASE, which is used when executing GRASS commands or scripts as part of the build process. On Unix, this will typically end up being identical to ARCH_DISTDIR, which is the base directory where generated files are placed. But on Windows, RUN_GISBASE needs to use Windows' native filename syntax, whereas everything else uses the Unix-like syntax of MinGW/MSys.
One possible solution is to have configure substitute WINDSTDIR rather than GISBASE and change Platform.make.in to:
RUN_GISBASE = @WINDSTDIR@/dist.$(ARCH)
That should ensure that ARCH_DISTDIR and RUN_GISBASE are equivalent even if ARCH is overridden on the command line.
comment:4 by , 8 years ago
Milestone: | 7.0.5 → 7.0.6 |
---|
follow-up: 6 comment:5 by , 7 years ago
comment:6 by , 7 years ago
Milestone: | 7.0.6 → 7.2.2 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Replying to lbartoletti:
Hi,
You can close this tickets, we have patched files for FreeBSD.
... solved in #2940, closing.
Replying to pieside:
The include flags are actually:
from Grass.make.
Headers are supposed to be installed in $(ARCH_INCDIR), which is set to
Note that ARCH_DISTDIR is set thus:
and both GRASS_HOME and ARCH appear to be set correctly in your attached Platform.make file:
Is it only headers that are in dist.amd64? Everything that will eventually be installed should be within the dist.amd64-portbld-freebsd11.0 directory except for the grass71 startup script, which should be in bin.amd64-portbld-freebsd11.0. Knowing which files go where would provide some clues as to the source of the problem.
I suggest that you examine the output from "make". If you didn't capture it to a file, run "make clean" then re-build with e.g.
Check for the "install" commands which install headers, e.g.
If those look okay, there's something wrong with the install program (or the install-sh script, if that's being used). Otherwise, the issue may be with the build system.