Conversation
The restriction on petsc versions to depend on boost seems to be overly restrictive ([email protected] seems to have the possibility to depend on boost too).
|
|
||
| # Other dependencies | ||
| depends_on('boost', when='@:3.5+boost') | ||
| depends_on('boost', when='+boost') |
There was a problem hiding this comment.
It looks like this was added in #2036 based on #1999 (comment). Ping @BarrySmith
There was a problem hiding this comment.
@alalazo there is also this comment #1999 (comment), so I guess we can indeed keep the version constraint.
There was a problem hiding this comment.
Perhaps the following change is more appropriate
# Other dependencies
- depends_on('boost', when='@:3.5+boost')
depends_on('metis@5:~int64+real64', when='@:3.7.99+metis~int64+double')
There was no direct dependency on boost even from old petsc versions.
There was some code in petsc which had this dependency - but this code was disabled by default. i.e - if petsc was configured with --with-sieve=1 - then it needed --with-boost=1. [sieve was never enabled in spack build of petsc - so boost was never required]
Now boost is primarily a depdendency for trilinos - so we would need --with-boost=1 for --with-trilinos=1 build. i.e for spack install petsc+trilinos
cc: @BarrySmith
There was a problem hiding this comment.
Also - perhaps the following change:
- variant('boost', default=True, description='Activates support for Boost')
variant('hypre', default=True,
And somehow add
depends_on('boost', when='@:3.8+trilinos')
options.append(with-boost=1) #in some if statement for petsc+trilinos
|
Thanks for the comments above @balay, will implement them asap. While we are at it, I am digging into the output logs and saw the following: ===============================================================================
***** WARNING: Using default optimization C flags -g -O
You might consider manually setting optimal optimization flags for your system with
COPTFLAGS="optimization flags" see config/examples/arch-*-opt.py for examples
===============================================================================
===============================================================================
***** WARNING: Using default C++ optimization flags -g -O
You might consider manually setting optimal optimization flags for your system with
CXXOPTFLAGS="optimization flags" see config/examples/arch-*-opt.py for examples
===============================================================================
===============================================================================
***** WARNING: Using default FORTRAN optimization flags -g -O
You might consider manually setting optimal optimization flags for your system with
FOPTFLAGS="optimization flags" see config/examples/arch-*-opt.py for examples
===============================================================================Are there changes you advise with respect to the above, or should I just inspect the examples mentioned in the WARNING and set the optimization flags? |
|
PETSc configure interface splits the usual CFLAGS into CFLAGS and COPTFLAGS options - this way - each flag has its own defaults [that configure sets] - and user can override them as desired. For eg: - on KNL - one my want to use: The reason we do this split is - for ex: configure might use defaults FFLAGS='-ffree-line-length-0' FOPTFLAGS='-O' - and when user wishes to change optimization flag - the FFLAGS default flag '-ffree-line-length-0' doesn't get removed [unless the user explicitly sets FFLAGS' etc..] Wrt spack - perhaps it controls the CFLAGS/FFLAGS used by all packages somehow [that the user can specify and override] - and passes these flags via CFLAGS/FFLAGS option to each package configure? If so - COPTFLAGS='' FOPTFLAGS='' CXXOPTFLAGS='' might be more appropriate. [i.e spack decides such things - and petsc configure uses what spack provides - and it doesn't guess stuff on its own..] |
|
I have these changes in branch balay/petsc-remove-boost-dependency i.e bf8fa37 |
|
@adamjstewart It seems both changes ( |
The restriction on petsc versions to depend on boost seems to be overly restrictive (
[email protected]seems to have the possibility to depend on boost too).