openems: init at 0.35.0

[matthuszagh]

OpenEMS is an open-source electromagnetic field solver that uses the FDTD method.

This commit adds a number of related packages as dependencies for OpenEMS, including appcsxcad, csxcad, fparser, hyp2mat, and qcsxcad.

Additionally, it makes a few changes to existing, dependent packages:

1. Adds QT GUI support to VTK.
2. Adds gl2ps as an optional dependency of octave, which is needed for certain OpenEMS plots.
3. Adds openmpi C++ libraries.
4. Makes cgal headers and libraries discoverable by OpenEMS.

Motivation for this change

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

Notify maintainers

cc @

[matthewbauer]

@GrahamcOfBorg eval

[matthuszagh]

Let me know if I need to do something on my end for this. I'm not really sure what that error message means.

[matthuszagh]

I've updated this to include the optional python interface.

[jonringer]

to conform to CONTRIBUTING.md, please make it so that roughly 1 commit = 1 package.

appcsxcad: init at 0.2.2
csxcad: init at 0.6.2
....

[matthuszagh]

Changes implemented. This currently fails to build because of qscintilla/octave, so just waiting on this pr.

[matthuszagh]

Octave has been fixed upstream. I've fixed the merge conflict and this now builds correctly.

[jonringer]

@GrahamcOfBorg eval

[matthuszagh]

Just a heads up, I believe the eval should succeed now that my name is in the maintainers list.

[matthuszagh]

@jonringer I've fixed the merge conflicts and got the package working with some other package updates that occurred since the original PR. Please let me know any issues etc. Thanks!

[jonringer]

I would break this PR apart into many. As it stands, it would take a lot to review and I think the process would be painful for the both of us.

[matthuszagh]

Sure, more than happy to structure this in a way that's easier on you all. How do you suggest I break it up? Roughly, each of those commits should be a separate PR? What's the best way to reference that all these changes are made to support the addition of openems? Just state that and link to the openems webpage? My only concern is that the need for some of these changes may seem less apparent outside the context of openems.

[jonringer]

#78772 is a good example.

Personally, i would break each commit into it's own separate PR (but only if it builds). So, I would cherry-pick the individual commits (which can be built off master), and when they get merged in, just drop the commits from this PR. Eventually, this should just include the openems: init at XXXX commit.

EDIT: grammar

[matthuszagh]

@jonringer thanks so much for the guidance on this. I've submitted the first PR. Others to follow that merge.

[jonringer]

@matthuszagh if you want to tag me for reviews, feel free to do so

[doronbehar]

There are merge conflicts.

[matthuszagh]

@doronbehar yes, this isn't ready to merge yet. I'm resubmitting it as a series of individual PRs. When there is one commit left, I'll rebase.

[jonringer]

I think most of these are merged, should we close?

[matthuszagh]

Sure, fine by me. Closing.