There is a bigger patch including all the changes for the consumers but I have just submitted the Mk framework patches. I am still unsure whether if I should make one big commit or should I make individual commits to convert to the new macro USES=octave.
Details
- Reviewers
stephen_missouri.edu tcberner - Group Reviewers
portmgr - Commits
- R11:8231864a3b03: Mk/**octave.mk: Convert to USES=octave
This is the last run of the consumers using the new USES macro:
~~ https://pdr.bofh.network/build.html?mastername=131-tex&build=2022-12-27_14h34m43s ~~
https://pdr.bofh.network/build.html?mastername=131-tex&build=2022-12-29_15h48m22s
Unless I have missed any consumers all builds fine.
Diff Detail
- Repository
- R11 FreeBSD ports repository
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Is it intentional that we request c++14 support but set gnu++11 in CXXFLAGS?
L1 and L2 should be removed and replaced with a short description instead?
Nah prehistoric garbage.
L1 and L2 should be removed and replaced with a short description instead?
If you delete the L1 and L2 the features and description comes on top. :v
I think as this replaces bsd.octave.mk, I would push it and the conversion of the tree in one big commit.
Mk/Uses/octave.mk | ||
---|---|---|
18 | ^ this looks the wrong way around. In my opinion the mk should provide the version and the Makefile get it from here. | |
38 | ^ do all octave-using ports require this, if not maybe add an argument :nosubdir? | |
52 | maybe define octave-preinstall, octave-do-install and ocatave-post-install and add it? pre-install: octave-pre-install ? |
Mk/Uses/octave.mk | ||
---|---|---|
38 | Yes this is required by all consumers. |
This includes the entire BIG patch to convert bsd.octave.mk to Mk/Uses/octave.mk including the updates requested by @tcberner
This looks good to me.
math/octave-forge-divand/Makefile | ||
---|---|---|
21 โ | (On Diff #114643) | ^ah, so there is at least one exception to the WRKSRC :D |
math/octave/Makefile | ||
---|---|---|
66 โ | (On Diff #114643) | ^ unrelated, could likely be USES=localbase |