Re: Multiple new R ports
Hi, Could a committer take a look at https://reviews.freebsd.org/D43735 for me? Adds 3 R modules, with dependencies, 13 new ports in total. Builds in poudriere and used in production. einar On 2/4/24 13:34, Einar Bjarni Halldórsson wrote: On 3 Feb 2024, at 18:56, Gleb Popov wrote: On Sat, Feb 3, 2024 at 6:31 PM Einar Bjarni Halldórsson wrote: Hi, I needed to create three new R ports, but with new ports for missing dependencies, it’s 13 new ports in total, all R packages. Should I create one PR for them all, or one for each package with blockers for dependencies? einar Single PR should be fine. You may also consider creating a Differential revision on our Phabricator. Thanks. I created a revision in Phabricator for all the ports. We’ll see how it goes. If needed, I can chop it up into multiple revisions. .einar
Re: Multiple new R ports
Hello, I did take a look at review and noticed that TEST_DEPENDS are not used and that could means that test target works without any depends or ports are not tested at all. My curiosity is what do you think about the importance (or not) to have testunit feature working on R ports? I maintain a couple R ports and testunit revealed some errors that upstream fixed. Maybe this testunit subject could be apply to all ports that have that feature. Thanks, Einar Bjarni Halldórsson escreveu (quinta, 22/02/2024 à(s) 08:40): > > Hi, > > Could a committer take a look at https://reviews.freebsd.org/D43735 for me? > Adds 3 R modules, with dependencies, 13 new ports in total. > > Builds in poudriere and used in production. > > einar > > On 2/4/24 13:34, Einar Bjarni Halldórsson wrote: > >> On 3 Feb 2024, at 18:56, Gleb Popov wrote: > >> > >> On Sat, Feb 3, 2024 at 6:31 PM Einar Bjarni Halldórsson > >> wrote: > >>> Hi, > >>> > >>> I needed to create three new R ports, but with new ports for missing > >>> dependencies, it’s 13 new ports in total, all R packages. > >>> > >>> Should I create one PR for them all, or one for each package with > >>> blockers for dependencies? > >>> > >>> einar > >> Single PR should be fine. You may also consider creating a > >> Differential revision on our Phabricator. > >> > > Thanks. I created a revision in Phabricator for all the ports. We’ll see > > how it goes. If needed, I can chop it up into multiple revisions. > > > > .einar > > > > -- Nuno Teixeira FreeBSD Committer (ports)
emulators/mame: Increasing option granularity woes
Hello, The current in-tree port of mame, 0.261, is built around the core multi-emulation framework, which results in the usual mega monolithic mame binary. There are options for TOOLS, which include two other emulators. The current upstream release, 0.262 has enabled separation of mame from the rest of the project—TOOLS can now be built separately. I would like to reflect this in the Port, however, that means moving the two added emulators (LaserDisk player, and Netlist resolver) out of TOOLS (which I think the correct path to take). Considering the new upstream build pattern, I would like to configure the Port to option any of the emulators, and existing TOOLS. The problem I am facing, the three emulators require the same (or close to it) runtime config/resources, the assets are currently covered by the do-install target[1], how do I cover the assets in the Port, specifically in the pkg-plist to be conditioned on either of 3 potential emulator options? Should I add an option MAMEDATA? But then that moves the problem to the user, why should the user make a choice to install the runtime data, if they select any emulator, the Port should automate that? How can I avoid fixing the data to only one emulator option? In summary, the current Port is structured as a monolith with optional tools (including two other emulators fixed to the bulk MAME build), enabling a Qt debugger for the emulators, enabling platform optimisation, and object production type. What I am attempting, which is not proving successful, a minimal port (which is a single project man page, tho would be nicer to have at a minimum TOOLS or at least one emulator), adding new options for the current 3 build-able emulators, separate TOOLS from the emulators, and a way to install the data if any emulator is selected, the last element being the most difficult. Any feedback would be muchly appreciated. 1: https://codeberg.org/FreeBSD/freebsd-ports/src/commit/7ec8098ee3483dc19cbd23e16139a737d601153a/emulators/mame/Makefile#L189 To anarchy and health, Alastair
Unmaintained FreeBSD ports which are out of date
Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ cad/ifcopenshell| 0.6.0 | blenderbim-240222 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout!
Re: emulators/mame: Increasing option granularity woes
On Fri, Feb 23, 2024 at 5:51 AM Alastair Hogge wrote:
>
> Hello,
>
> The current in-tree port of mame, 0.261, is built around the core
> multi-emulation framework, which results in the usual mega monolithic
> mame binary. There are options for TOOLS, which include two other
> emulators. The current upstream release, 0.262 has enabled separation of
> mame from the rest of the project—TOOLS can now be built separately. I
> would like to reflect this in the Port, however, that means moving the
> two added emulators (LaserDisk player, and Netlist resolver) out of
> TOOLS (which I think the correct path to take). Considering the new
> upstream build pattern, I would like to configure the Port to option any
> of the emulators, and existing TOOLS. The problem I am facing, the three
> emulators require the same (or close to it) runtime config/resources,
> the assets are currently covered by the do-install target[1], how do I
> cover the assets in the Port, specifically in the pkg-plist to be
> conditioned on either of 3 potential emulator options? Should I add an
> option MAMEDATA?
You're almost right. Indeed there is no need in the user-visible
option, but you want all other machinery to kick in.
Basically, it boils down to
if somecond
PLIST_SUB+=MAMEDATA=
else
PLIST_SUB+=MAMEDATA="@comment "
endif
where "somecond" defines if the files should be present in the
package. For OPTIONS (and when OPTIONS_SUB=yes is present [1]) it
happens automatically.
If you end up with "somecond" being in form "${PORT_OPTIONS:MFOO} ||
${PORT_OPTIONS:MBAR}" then you could simplify it even more
FOO_PLIST_SUB= MAMEDATA=
FOO_PLIST_SUB_OFF= MAMEDATA="@comment "
BAR_PLIST_SUB= MAMEDATA=
BAR_PLIST_SUB_OFF= MAMEDATA="@comment "
[1] https://docs.freebsd.org/en/books/porters-handbook/makefiles/#options_sub
