From: Chris Billington Subject: Re: [new]: Ringdove EDA suite, successor to cad/geda-gaf To: Stuart Henderson Cc: ports@openbsd.org Date: Thu, 4 Dec 2025 22:52:57 +0800 Thanks- I think I have picked up some of your points in the later versions but will go though carefully all you said. Upstream uses their own configure system 'scconfig' (except for genht) which gets built from source on each run. Initially I used configure "simple" but there were issues I can't recall now so I changed it to 'none'. I'll try simple again. The upstream developer is a quite unusual character with strong opinions about modularity in particular. Initially I had done monolithic ports with a basic set of configure options, and contacted him with questions about the scconfig system and how to override paths (it's a bit non standard, very un-GNU). He was very insistent that ports must be modular and follow the packaging listed in detail on the upstream website.  I said we would not normally split things to that extent but he explained that it was carefully constructed like that so he could offer effective support, and to make it work cross platform and with different gui toolkits. He then said if we didn't split like that he would refuse to provide any support to those using the suite on OpenBSD. Debian seems to be the main platform used in production. What to do about that? So I have gone with the structure he recommends with the exception of a -dev package containing headers, a debianism. By installing different subpackages the gui can be gtk2-gdk, gtk2-gl, gtk4-gl or motif. Same with different kind of import/export options. The same with scripting, which only pulls in python/lua/tcl if the subpackage is installed, otherwise base perl/awk can be used instead. Despite the slightly inflexible attitude upstream, the software is mature, the main developer helpful, and the suite is very well thought out- my background is in electronics and cad, and I am impressed with the workflow and attention to detail. The port-lib-depends-check target runs OK in the latest versions. It only complains about libfungw (the scripting gateway) which has to be a separate dependency if python/perl/tcl,/lua scripting is wanted, and it's therefore not part of the fake-amd64 tree. So should fungw be a WANTLIB rather than Lib/build dependency? Thanks for all your comments. I will try and polish the ports some more to make them acceptable. Chris 4 Dec 2025 22:05:31 Stuart Henderson : > some comments from reading the files in your tars, I've not > tried building, don't have time for a full review and not > particularly interested in this software myself. > > don't set do-build to just run make, or set do-configure to just > run configure, that is normal behaviour > > "CONFIGURE_STYLE=none" was a hack for some things using > MODULES=lang/python due to an issue with how python.port.mk used to > work but shouldn't be used now. from reading the ports makefiles it > looks like these should set to either "gnu" or "simple" depending > on whether the scripts being run are gnu autoconf scripts or some > other configure scripts > > various version numbers (lua, python, tcl) hardcoded should use > variables from the relevant modules > > configure is only run once, you can't set CONFIGURE_ARGS per > subpackage (can't remember if you fixed that in later versions or > not) > > for which don't use C++, if you set COMPILER you should also set > COMPILER_LANGS=c. (I'm not sure whether you need to set COMPILER or > not for these). > > the various things with BUILD_DEPENDS and RUN_DEPENDS pointing at > libraries makes me think there is some confusion around libraries > which should normally use LIB_DEPENDS and have WANTLIB entries > > re the metapackages in the later tar; we don't split packages up > to that extent. only reason I see for splitting camv-rnd would be if > some of the plugins had different (and large) library dependencies > to cut those down (as done in asterisk, php, etc) but I'm not seeing > that here. > > COMMENT should starts lowercase except for proper nouns > > 'Sample configuration files are installed in [...]' - > this is ports standard and doesn't warrant a MESSAGE > > i suspect "make port-lib-depends-check" will complain about quite a > lot of things. > > there are various things setting variables to the default; in particular > the multi packages things using PKGNAME-x - do "make show=PKGNAMES" as-is > and with those lines removed/commented and compare; it should give the > same in both cases. that then gets rid of uses of ${V} and then you > would just write e.g. DISTNAME=fungw-1.2.2 rather than setting V. > > shared library version numbers start from 0.0 in ports. > > we don't do the linux symlinking thing for libraries (eg. in genht > do-install).