Configuration file to install Xyce as a Spack package with shared libraries enabled

86 views
Skip to first unread message

Renaud GILLON

unread,
Jan 17, 2022, 8:44:24 AM1/17/22
to xyce-users
Hello,

Recently, I noticed that the xyce configuration file for spack did not allow to activate the shared libraries features, because no variant() was setup at the top-level of the class. So I made the following changes (adding those lines)  :

57a58,60
>     # Activating shared libraries
>     variant('shared', default=False, description='Enable shared libraries for Xyce')
>
and was able to install Xyce (serial build with Python interface and shared libs activated) with the following command:

> spack install xyce -mpi +pymi +shared

Most test-cases ran correctly except about 70 of them (I did not investigate root causes in depth yet).

Question: is it on purpose that no variant() is defined in the original xyce config file for spack or should this be corrected ? 

Regards,


Renaud

xyce-users

unread,
Jan 17, 2022, 9:16:57 AM1/17/22
to xyce-users

The spack install for Xyce was produced as part of a research project and is not fully supported or documented, and is not yet recommended as a method of installing Xyce for most users.  The options chosen for that install were strictly set up for that particular project.

70 test failures is a bit concerning, but if changing the spack configuration works for you in other ways, then perhaps it's a good change.  The person who maintains the spack configuration is not on this email distribution list, and we'll make sure to get this information to him.

xyce-users

unread,
Jan 17, 2022, 5:41:58 PM1/17/22
to xyce-users

`+shared` was intended to be supported as a variant, but wasn't included in the variants list as an oversight. There are already checks against the `spec` to make the appropriate CMake changes when as user adds `+shared`.

 

```

        if '+shared' in spec:

            options.append('-DBUILD_SHARED_LIBS:BOOL=ON')

        else:

            options.append('-DBUILD_SHARED_LIBS:BOOL=OFF')

```

PR https://github.com/spack/spack/pull/28469 is now open which will integrate the change you suggested along with the option to specify Xyce 7.4.0. Thank you for sharing your experience with the spack installation and do please keep in mind that it is not currently fully supported and documented, as was mentioned previously.


On Monday, January 17, 2022 at 6:44:24 AM UTC-7 renaud...@gmail.com wrote:

renaud...@gmail.com

unread,
Jan 18, 2022, 2:43:30 AM1/18/22
to xyce-users
Yes, I noticed that, indeed, the mechanics underneath had been setup, just the top-level API was lacking one definition.

From my perspective (not using the latest bleeding edge system), and after experimenting with Conda environments, spack looks like a very appealing solution. At least for me it was the easiest way to get the Xyce sources and dependencies installed and compilation running. I had done this in the past "the standard way" (not spack based) and it had been much more effort intensive, less documented, etc.

At the moment, the benefits of spack seem to be of such magnitude, that it is more advantageous for me to work on improving the spack setup for Xyce and to try through other ways.

Thanks for submitting the pull request on the spack repo.


Renaud

renaud...@gmail.com

unread,
Jan 18, 2022, 4:27:29 AM1/18/22
to xyce-users
When running the regression suite on the Xyce generated using the customized spack configuration, I am now getting 10 failures (instead of the originally reported 70), one crash and 9 "exited with error" (which look like expected things). The issue was related to spack-installed Python not having the Numpy and Scipy modules installed. Solved it by unloading the spack-installed Python and get back to a Cond environment configured for data-science. In attachment the list of remaining failures from the Xyce regression suite 7.4.
spack_serial_failures_20220118
Reply all
Reply to author
Forward
0 new messages