Use native make(1) mechanism to create the package repository directory

[bapt]

Summary

In order to have subpackages we need in the end do-package to depend on
a target per package that would be created per subpackages

For this we need to decouple the content of do-package so it becomes
a target that only creates the packages.

As a first step use natural make(1) mechanism for a target: if checks first
for the existence of a file and it it does not exists that execute the content
of the target, in that case it creates the PKGREPOSITORY
Bonus it simplifies a bit the code.

While here to avoid testing multiple time for the PACKAGES directory set a
variable after we tested it the first time

[mat]

Mk/bsd.port.mk

3347–3348 ↗

(On Diff #24817)

There already is a target for creating directories around line 2947, maybe you could add PKGREPOSITORY to it (keep the _EXTRA_PACKAGE_TARGET_DEP here, or move it to where you set _JAVE_PACKAGES earlier, maybe)

[bapt]

Factorize mkdir

[mat]

Mk/bsd.port.mk

3354–3355 ↗

(On Diff #24824)

I'm not sure why we need two lines, it should work just fine with:

do-package: create-manifest ${_EXTRA_PACKAGE_TARGET_DEP} ${TMPPLIST}

[antoine]

It doesn't seem to work

<phase: extract >

> License BSD2CLAUSE accepted by the user

> Fetching all distfiles required by pkg-1.10.0_1 for building

> Extracting for pkg-1.10.0_1

> License BSD2CLAUSE accepted by the user

> Fetching all distfiles required by pkg-1.10.0_1 for building

> SHA256 Checksum OK for pkg-1.10.0.tar.xz.

cd: /wrkdirs/usr/ports/ports-mgmt/pkg/work: No such file or directory

• Error code 1

[bapt]

Fix order new target is define

[bapt]

Only use oneline to define the do-package dependencies

[bapt]

Everything should be addressed

Mk/bsd.port.mk

3347–3348 ↗

(On Diff #24817)

I plan more cleanup in a second patch

[bapt]

Create the prefix in stage directory using the new target

[mat]

Mk/bsd.port.mk

3094 ↗

(On Diff #26902)

This should not be needed, the directory is in the _EXTRACT_SEQ pipeline.

3347 ↗

(On Diff #26902)

Wondering if all those dependencies could not go in the _PACKAGE_SEQ pipeline.

4531 ↗

(On Diff #26902)

same here in _STAGE_SEQ

[bapt]

The advantage of not going in the SEQ is to be allow parallelisation.

the SEQ is mainly for things that cannot be run in parallel and where the dependencies are hard to express aka the public or main big ones or the one added via USES because we never know.

that said if you have a strong feeling about only having targets in SEQ we can do it.

[bapt]

I do like explicit dependencies when it is easy to express, has when hacking on a given target you exactly know what you depend on :)

[mat]

In D9466#211552, @bapt wrote:

The advantage of not going in the SEQ is to be allow parallelisation.

the SEQ is mainly for things that cannot be run in parallel and where the dependencies are hard to express aka the public or main big ones or the one added via USES because we never know.

that said if you have a strong feeling about only having targets in SEQ we can do it.

I'm not sure it is a good idea to have most targets in _SEQ and have a handful of targets outside of it. I don't really see a point of being able to parallelize a MKDIR :-)

[mat]

What I mean is, if some day, it is rewritten and the _SEQ things go away, fine, but right now, it is the way the targets in b.p.m work, so it could be a good idea to stick with it.

[bapt]

The failures antoine show was due to the dependencies only being in the SEQ because the variable was expanded to early. with the explicit dependency added we are sure it never fails again.
actually all directories/files dependencies should imho in anycase be removed from the SEQ. I can work on that after if you want.

[bapt]

Define the mkdir target prior to the SEQ definition so it always exists