Conversation
| # See the Spack documentation for more information on packaging. | ||
| # If you submit this package back to Spack as a pull request, | ||
| # please first remove this boilerplate and all FIXME comments. | ||
| # |
There was a problem hiding this comment.
You can remove all of this template stuff below the license.
There was a problem hiding this comment.
Sorry, missed that one.
| depends_on('[email protected]:', type='build') | ||
| depends_on('zlib') | ||
| depends_on('flex') | ||
| depends_on('bison') |
There was a problem hiding this comment.
Flex and bison are usually type='build' dependencies.
| depends_on('flex') | ||
| depends_on('bison') | ||
| depends_on('proj') | ||
| depends_on('gdal') |
There was a problem hiding this comment.
I was actually thinking about adding a GRASS package when I was working on GDAL. I noticed that GDAL has a --with-grass option, but that would create a circular dependency. Can you comment on whether GRASS should be built with GDAL or GDAL should be built with GRASS? I'm not too familiar with GRASS.
There was a problem hiding this comment.
This is a circular piece. As I recall, you first build gdal without grass, then build grass, then build gdal with grass. I could code this in as gdal~grass then have gdal to just code grass, So gdal+grass should be able to compile then.
There was a problem hiding this comment.
Nah, I don't think that will work at the moment. Spack doesn't let the same package occur multiple times in the DAG, even if one is gdal+grass and the other is gdal~grass. I don't think it's possible to build GDAL with GRASS support at the moment.
| args.append('--without-cxx') | ||
|
|
||
| if '-tiff' in spec: | ||
| args.append('--without-tiff') |
There was a problem hiding this comment.
I like to be explicit and say:
if '+tiff' in spec:
args.append('--with-tiff')
else:
args.append('--without-tiff')for all dependencies. Otherwise, a lot of build systems will build optional support if they can find the dependency on the OS. We don't want these kind of non-deterministic builds in Spack.
There was a problem hiding this comment.
+tiff is the default, which will load up libtiff. Mine is not as symmetrical as it follows the configuration file - which probably will change at any time, so your way is better.
|
I also loaded up opengl - shouldn't this be mesa? I suppose that I could have both opengl and mesa options with a constraint that it could not be both at once. |
You should use the virtual dependency |
| depends_on('bison', type='build') | ||
| depends_on('proj') | ||
| depends_on('gdal') | ||
| depends_on('[email protected]:2.9') |
There was a problem hiding this comment.
Yes, for python. Shouldn't the proj/gdal be build,link,run? Also, should this be named grass7 to be more consistent with its r routine r-rgrass7?
There was a problem hiding this comment.
Depends on how proj/gdal are used by the package.
Don't worry about the R package, we don't want several grass packages if they are all the same.
There was a problem hiding this comment.
I have found that if you do not include the link for routines with pkgconfig directories, it breaks the chain. See libxfixes and libxi changes in 8450.
2 participants
Add the grass gis system.