buildxyceplugin

[Murat H Eskiyerli]

I wonder why buildxyceplugin is not included in rpm for Xyce. I used to compile my own Xyce when using Manjaro including buildxyceplugin. I have recently switched to OpenSuse as it is rpm based and I thought it would be a less of a hassle. However Xyce rpm I downloaded from Sandia site does not include buildxyceplugin script. 

Murat Eskiyerli

[Thomas Russo]

It's because the RPM builds of Xyce are built in such a manner that plugins don't actually work.  Xyce is linked statically (that is, it is configured without "--enable-xyce-shared" and "--enable-shared").  The entire plugin system depends on the build being shared for arcane reasons (it *would* be possible to make a plugin system that worked with a static build of Xyce, but this one isn't it).  For that reason, when you configure Xyce without those options, buildxyceplugin isn't even created lest someone try to use it and discover it doesn't work (it'll gleefully create a plugin that will fail with unresolved Trilinos symbols when you try to load it into Xyce).

I honestly can't remember *why* we always distributed Xyce linked statically that way, but I do remember that whenever we tried to distributed binaries that were made with "--enable-shared" and "--enable-xyce-shared" there was some sort of problem (either on the building end or when people actually tried to use it).  Unfortunately, I can't for the life of me remember what all of those problems were, only that we never worked through them all and so just kept distributing the build in exactly the same way year after year.  Perhaps the Xyce team now has the staff cycles to work out all the issues that made that not work in the past and will do shared build distribution in the future.  All I can say is that when I worked there, there were so many more important things to work on that it never rose to the top of the stack of work.  

[Thomas Russo]

I just remembered *one* of the reasons Xyce is distributed that way.

The Xyce team uses the Intel C++ compiler to build Xyce, because at one time it was determined that compiler produced better-optimized code.  This compiler costs real money to use if you don't work somewhere where they have site licenses.

Building plugins requires that you use the same compiler to build the plugin that you used to build the code itself (or rather, buildxyceplugin *expects* to be able to build the plugin with that same compiler).  Thus, if we distributed the shared library version you *still* couldn't use the buildxyceplugin script unless you *also* had the Intel compiler.

Sometime in 2022 I spent time trying to update the Xyce binary packaging system to make it *possible* to distribute a GCC-compiled shared build so that ordinary RHEL users could use the plugin system (if you poke around in the git history of the "distribution" directory you can see signs of that work).  While that actually made it possible to bundle up the code of a shared build into an RPM, it didn't work for a number of reasons, including the fact Trilinos had started requiring a compiler that fully implemented C++11, and RHEL7 bundled a version of GCC that was too old to use.  One had to use the Red Hat "development tools" to obtain a less ancient version of GCC, but then we're back to the same problem --- a user outside Sandia would then not be able to use the plugin build system unless they *also* had paid for the development tools subscription, which we couldn't count on.

So in the end, we just kept distributing static builds that work but don't include a usable plugin system.

[Murat H Eskiyerli]

Thanks for the explanation. I think there is now work being done to update Verilog-a module infrastructure in Xyce. Depending on the result of that work, this might become a moot point. In the past, I had tried to release Xyce with plugin and Revolution EDA in container. Because it included a GUI program, some users had experienced problems getting it working. 

In a related note, I tried vacask simulator written by Arpad Buerman. All models except for some very fundamental primitives are in Verilog-a and it uses OpenVAF reloaded. It already has usual analyses such DC, AC, TRAN, XF, NOISE and HB.