Page MenuHomeFreeBSD

Add CONFIGURE_OUTSOURCE support
ClosedPublic

Authored by jbeich on Nov 14 2015, 10:43 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 7, 7:05 PM
Unknown Object (File)
Thu, Nov 7, 3:17 PM
Unknown Object (File)
Thu, Nov 7, 10:02 AM
Unknown Object (File)
Tue, Nov 5, 3:28 PM
Unknown Object (File)
Tue, Nov 5, 2:08 PM
Unknown Object (File)
Sun, Oct 27, 3:17 PM
Unknown Object (File)
Sun, Oct 27, 3:16 PM
Unknown Object (File)
Sun, Oct 27, 3:16 PM

Details

Summary

Teach HAS_CONFIGURE how to build outside of source tree similar to USES=cmake:outsource and USES=qmake:outsource. The basic idea can be illustrated as:

$ mkdir ../.build
$ cd ../.build
$ ${OLDPWD}/configure
$ gmake
$ gmake install
Initial version hooked into USES=autoreconf like devel/fb-adb. Current version is generic and may work with non-autoconf produced configure scripts.
Test Plan
  1. Pick a simple port with HAS_CONFIGURE=yes or GNU_CONFIGURE=yes
  2. Add CONFIGURE_OUTSOURCE=yes
  3. Adjust paths in *-install target(s) if necessary
  4. Build
  5. Run make check-plist stage-qa
  6. Repeat skipping 2nd step

For example, 1-5 can be simplified to

$ nice poudriere bulk -Ctj 101i386 \
  $(diffstat -l /path/to/this.diff | sed -n '/Mk/d; s,/Makefile,,p')

https://people.freebsd.org/~jbeich/D4157/
exp-run in bug 208294

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

jbeich retitled this revision from to Add USES=autoreconf:outsource support.
jbeich updated this object.
jbeich edited the test plan for this revision. (Show Details)
jbeich added a reviewer: tijl.

I think the idea is great, but that USES=autoreconf is the wrong place for this. The output of autoreconf is still inside WRKSRC. It's the output of configure that is moved out so you should implement something like GNU_CONFIGURE=outsource.

jbeich edited edge metadata.
  • Convert USES=autoreconf:outsource to HAS_CONFIGURE=outsource or GNU_CONFIGURE=outsource
  • Add multimedia/ffmpeg as an example for HAS_CONFIGURE=outsource
  • Remove devel/google{test,mock} as uninteresting examples
In D4157#87491, @tijl wrote:

The output of autoreconf is still inside WRKSRC.

Did you miss WRKSRC != CONFIGURE_WRKSRC ? USES=autoreconf currently uses the latter and has to be patched. Moved to D4169.

It's the output of configure that is moved out so you should implement something like GNU_CONFIGURE=outsource.

OK but AUTORECONF_WRKSRC maybe out of sync with CONFIGURE_CMD.

jbeich edited edge metadata.

I think phabricator got confused. The diff doesn't apply to the ports tree.

jbeich edited the test plan for this revision. (Show Details)

The diff doesn't apply to the ports tree.

I've somehow reverted D4169 while splitting the diff. Fixed.

jbeich retitled this revision from Add USES=autoreconf:outsource support to Add HAS_CONFIGURE=outsource support.Nov 17 2015, 8:58 AM
jbeich updated this object.
jbeich edited the test plan for this revision. (Show Details)
jbeich edited edge metadata.
jbeich updated this object.

Ping before 2016Q2. Exp-run in bug 208294.

  • Renamed HAS_CONFIGURE=outsource to CONFIGURE_OUTSOURCE=yes in order to simplify logic
jbeich retitled this revision from Add HAS_CONFIGURE=outsource support to Add CONFIGURE_OUTSOURCE support.Mar 25 2016, 7:14 PM
jbeich edited edge metadata.
  • Fixed typos in docstrings (CHANGES, Mk/bsd.ports.mk comment)
mat added inline comments.
Mk/bsd.port.mk
1558 ↗(On Diff #14611)

This could be build, without the ., nothing writes directly inside WRKDIR nowadays.

2608 ↗(On Diff #14611)

I feel this is not needed any more, right ?

jbeich edited edge metadata.
  • Fixed typo from rename found by @mat.
Mk/bsd.port.mk
1558 ↗(On Diff #14611)

This was taken as is from USES=cmake:outsource, including the dot. And individual ports may and do write under WRKDIR sometimes. However, I'm not sure if any write under ${WRKDIR}/build in particular except candidates for conversion like lang/gcc.

2608 ↗(On Diff #14611)

Correct. ;)

Mk/bsd.port.mk
1558 ↗(On Diff #14611)

Ok, all the ports write to WRKSRC, if you have more than one distfile, you may have more than one subdirectory, but *nothing* should write to WRKDIR.
I know where it was taken from, but it comes from a time where ports might extract stuff to WRKDIR, now none of them do that.
Now, I said "could", not "should" or "must" ;-)

jbeich edited edge metadata.

Replaced example consumers that won't land

  • multimedia/ffmpeg
  • sysutils/fusefs-simple-mtpfs

with those that will land

  • audio/oss
  • devel/fb-adb (from previous version)
jbeich edited edge metadata.

lang/gcc* et al. are converted. I've left out marino's and lev's ports as they require more extensive changes:

  • cad/ghdl
  • devel/gcc-arm-embedded
  • devel/gcc-msp430-ti-toolchain
  • devel/mingw32-gcc
  • lang/gcc-aux
  • lang/gcc5-aux
  • lang/gcc6-aux
  • lang/gnatdroid-armv7

Oops, forgot to attach some commits.

jbeich edited edge metadata.
  • lang/gcc*: unbreak full-regression-test target
  • lang/gcc*, devel/psptoolchain-gcc-stage1: drop missed ${MKDIR} ${CONFIGURE_WRKSRC} from
  • devel/psptoolchain-gcc-stage1: use PATCH_WRKSRC which is slightly more correct
jbeich edited edge metadata.

Rebased after rP412346, rP412393 and converted a few more ports:

  • lang/squeak
  • devel/omniNotify
  • devel/py-omniorb*
jbeich edited edge metadata.

@ian, can you approve devel/arm-none-eabi-gcc492 hunk?
@bapt, can you approve devel/powerpc64-gcc hunk?
@bofh, can you approve devel/py-omniorb hunk?

If you don't have time this can go under portmgr blanket as well. Ignore me abusing approvals as an (implicit) voting system. ;)

Seems like py-omniorb is alright with the change.

Since review is progressing slowly (alas portmgr cannot timeout) I wonder whether to rename CONFIGURE_OUTSOURCE into OUTSOURCE_CONFIGURE. It'd follow the same vein as HAS_CONFIGURE, GNU_CONFIGURE discarding value unlike CONFIGURE_ENV, CONFIGURE_ARGS.

Since review is progressing slowly (alas portmgr cannot timeout)

Ok, hum:

  1. is the code working and finished ? (talking about the Mk bits)
  2. did you have an exp-run ?
  3. did it have any fallout, was it fixed ?
  4. why did you not commit it then ?

If you have yes to 1, 2 and 3, and nobody told you "HELL NO!", then 4 should have happened.

In D4157#126470, @mat wrote:
  1. is the code working and finished ? (talking about the Mk bits)

Mk/ bits stabilized mid November 2015, or the end of March 2016 if you count rename. Finding candidate consumers and converting them to the new style was always optional. A few are still left listed in D4157#122801 + multimedia/handbrake.

  1. did you have an exp-run ?

Yes per D4157#122622 but before D4157#124286.

  1. did it have any fallout, was it fixed ?

None.

  1. why did you not commit it then ?

Maintainers are supposed to vet changes for style, better approach, etc. If they want to rubberstamp an exp-run then it should be explicit.

If you have yes to 1, 2 and 3, and nobody told you "HELL NO!", then 4 should have happened.

I'm confused. Are you implying regular ports/ committers can time out portmgr ? According to Porter's Handbook:

If the maintainer does not respond to an update request after two weeks (excluding major public holidays), then that is considered a maintainer timeout, and the update may be made without explicit maintainer approval. ... Exceptions to this are anything maintained by the Ports Management Team <portmgr@FreeBSD.org>, or the Security Officer Team <security-officer@FreeBSD.org>. No unauthorized commits may ever be made to ports maintained by those groups.

mat added a reviewer: mat.

If you have yes to 1, 2 and 3, and nobody told you "HELL NO!", then 4 should have happened.

I'm confused. Are you implying regular ports/ committers can time out portmgr ? According to Porter's Handbook:

No, I'm not saying that, but there was hardly no answer from anyone, if you're waiting for a rubber stamp saying go ahead, please, go ahead.

This revision is now accepted and ready to land.Apr 13 2016, 10:14 AM
This revision was automatically updated to reflect the committed changes.