ngspice: update to 35 and fix issue with binary not built/installed

[mtboehlke]

General

• This is a new package and it conforms to the quality requirements

Have the results of the proposed changes been tested?

• I use the packages affected by the proposed changes on a regular basis and confirm this PR works for me
• I generally don't use the affected packages but briefly tested this PR

close #32251

(edited PR title to be more clear)

[ericonr]

Even if unnecessary, I wonder if we should make ngspice depend on libngspice... This way people's systems won't be broken.

Also, this PR needs to revbump kicad to pick up the new dependency.

Another possible solution is creating a ngspice-progs subpackage, but that feels kind of ugly.

[mtboehlke]

I included the revbump to kicad.

What exactly would happen if we don't have ngspice depend on libngspice?

[ericonr]

What exactly would happen if we don't have ngspice depend on libngspice?

Basically that someone who installed ngspice locally to use the libraries in their own projects would no longer be able to run them. That doesn't matter for most cases, since those people will usually have ngspice-devel installed as well.

[mtboehlke]

I see what you're saying.

As far as the checks go, apparently since v34 you have to add a .spiceinit file to the home directory containing set ngbehavior=mc. They pass on my machine after doing that.

[ericonr]

You can create a pre_check exporting a custom HOME and creating the file, if you want to run the tests :)

[mtboehlke]

Well, while playing with this I noticed that version 35 has been released. Removing the erroneously included files is no longer needed. Thanks for the tip for including pre_check! The only thing I haven't included is a libngspice dependency in ngspice, since it doesn't really seem necessary and doubles the install size for those just looking to use ngspice (admittedly install size probably isn't a big deal either), but I can add it too if we want to go that way.

[ericonr]

I like the shape this is taking, nice job :)

[mtboehlke]

:)

[sgn]

I think it's better to remove --with-readline=yes from configure_args then

Suggested change

	# Configure can handle building ngspice as a library or as a binary, but not both at once.
	# --with-ngshared builds the library, but not binary, and readline should not be configured for the library,
	# see: https://github.com/imr/ngspice/commit/b86c85f85bbba6e45dc030af3e853edf8b9cfa3d
	pre_configure() {
	install -d .build_lib
	cd .build_lib
	../configure --with-ngshared ${configure_args/--with-readline=yes/}
	}
	# library built during first do_build, now build the binary
	post_build() {
	make_build_args= do_build
	}
	do_configure() {
	mkdir build-lib
	cd build-lib
	../configure --with-ngshared ${configure_args}
	mkdir build
	../configure --with-readline=yes ${configure_args}
	}
	do_build() {
	make -C build-lib ${makejobs}
	make -C build ${makejobs}
	}

[mtboehlke]

Applied suggestion, with just minor tweaks

[sgn]

And:

Suggested change

	post_install() {
	vlicense COPYING
	cd .build_lib
	do_install
	}
	do_install() {
	make -C build-lib install
	make -C build install
	vlicense COPYING
	}

[mtboehlke]

It does seem clearer this way. I kind of liked not touching do_install, etc., to keep defaults and things, but maybe it just makes it a bit confusing at this point.

[mtboehlke]

I am pretty happy with this version of the template. Functionally these last set of changes seem to do the same as the last, but make it clearer what it's doing. Thanks for all the helpful feedback so far!

[mtboehlke]

I went ahead and did a rebase since my branch was old.

[mtboehlke]

@ericonr I am not a KiCad user ( or even really an ngspice user), but I was curious about the /usr/lib/ngspice/*cm files. It appears that they are code models used by the xspice extension. They can be used from KiCad, and should be made available, which this PR would break right now. My question is how best to handle that. Should they be moved to libngspice and have ngspice then depend on it as well, make another subpackage called something like ngspice-common, or maybe not split off libngspice at all? (PR reflects first option)

[ericonr]

My question is how best to handle that. Should they be moved to libngspice and have ngspice then depend on it as well, make another subpackage called something like ngspice-common, or maybe not split off libngspice at all?

I'm honestly ok with the last option.

[mtboehlke]

Sounds good! I went ahead and pushed changes to no longer split a libngspice package. Builds okay on my system.

[ericonr]

Ok, I think this still requires a kicad rebuild for some godforsaken reason :/

I can test and confirm tomorrow.

[mtboehlke]

Oh, there might be a issue if the version in the repo was linked against readline, which I'm pretty sure it is. We may want to rebuild kicad anyway just to be safe.

[ericonr]

It's worse ;) it tries to dlopen libngspice.so.0.0.0, but the new file is libngspice.so.0.0.1

[ericonr]

Thanks! I pushed the kicad change and merged.

[mtboehlke]

:) Thanks ericonr!