Add a simple way to have USES add targets.

[mat]

Summary

This allows USES to add targets easily and have them run whenever they want without touching bsd.port.mk.

To add a target that runs around the time post-configure run, do:

_USES_configure+=  700:my-post-configure
my-post-configure:
        do something

To fine tune when the target is ran, look at the values in the *_SEQ variables at the end of bsd.port.mk, and the other USES.

[mat]

Convert a few other targets.

Note that libtool and autoreconf are now most likely not being run in the same
order as before, which is bad, obviously.

[mat]

Convert to a numbering order scheme.

[mat]

• No real need to check if the target exists, it has a new name now.
• dos2unix
• erlang (and us real do-* targets)
• uniquefiles.
• webplugin
• Add sanity to the list.
• zope.

[mat]

• ncurses.
• Always put the _USES_foo just before the target.

[mat]

With a version that actually passes make -V *_SEQ

[mat]

With the _EXTRACT_SEQ correctly numbered.

[mat]

Rebase.

[mat]

• Correct documentation, wrap, and put additions at the end of the

[bapt]

I like it a lot!

code looks ok to me, I would like a file to list the targets so one can easily figure out which slots is available and in which order they are going to be run :)

Mk/Uses/display.mk

30

why turning it in :: ?

Mk/Uses/zope.mk

83 ↗

(On Diff #7258)

I suspect :: is not needed anymore

[mat]

In D3099#64349, @bapt wrote:

I like it a lot!

good :-)

I also did an exp-run, on friday/saturday with that, I have not looked at the result yet.

code looks ok to me, I would like a file to list the targets so one can easily figure out which slots is available and in which order they are going to be run :)

Well, maybe a target could be added, say, you run make all-targets or make targets, or something and it tells you all targets that can be run and the order, for the first, and the targets that will really be run, with the order, for the second ?

Or am I not getting what you are saying ?

Mk/Uses/display.mk

30

Mmmm, no reason, I'll revert, I was under the impression that it was the same, but no need to change that.

Mk/Uses/zope.mk

83 ↗

(On Diff #7258)

true.

[mat]

Targets don't need to be PHONY or :: any more.

[bapt]

code looks ok to me, I would like a file to list the targets so one can easily figure out which slots is available and in which order they are going to be run :)

Well, maybe a target could be added, say, you run make all-targets or make targets, or something and it tells you all targets that can be run and the order, for the first, and the targets that will really be run, with the order, for the second ?

it exists:

make -V.ALLTARGETS

But that is not what I am asking for :)

Or am I not getting what you are saying ?

I would like a files with the complete list of what exists (not only for my port)
because we have numbered them for a reason: always control in which order they will be run.
so haveing a target.list with <number>: name
will allow to have a quick view on the slots already used and what number I should pick because I'm about to add a new target in the Mk/Uses/*

[mat]

In D3099#64712, @bapt wrote:

I would like a files with the complete list of what exists (not only for my port)
because we have numbered them for a reason: always control in which order they will be run.
so haveing a target.list with <number>: name
will allow to have a quick view on the slots already used and what number I should pick because I'm about to add a new target in the Mk/Uses/*

Well, this file would need to be generated anyway, because otherwise, it would mean it would have to be kept in sync with the code, which will never work.

[bapt]

It would work if the number was actually picked from that file instead of XXX:bla just use bla and if no number is assigned in targetlist.txt yell

[mat]

In D3099#64732, @bapt wrote:

It would work if the number was actually picked from that file instead of XXX:bla just use bla and if no number is assigned in targetlist.txt yell

Been thinking about it some more on IRC, the only way I see it working is if targetlist.txt is a file that is not used for anything except as a reference of the existing targets, and that is regenerated by some script each time a target is added.

If something needs to be read from this file, then, it defeats the purpose of the _USES_* variables, which were here so that people would not touch bsd.port.mk when adding a target to USES, then, if it's a Makefile, it would replace all the _*_SEQ variables and be included here, so it would not be different than keeping it here, and if it's not a Makefile, it needs to be parsed, and it would mean adding a lot of cycles each time bsd.port.mk is parsed because it'd be some kind kind of run-this-command target.

[mat]

• Move the options target helper numbering in bsd.options.mk.
• Allow the port's Makefile to override the priority of an option target

[mat]

• Make it work if the variable is not set.

[mat]

With the latest addition, I can change the priority of an option target helper in each Makefile. For example, the default being:

$ make -V OPTIONS_TARGET_ORDER_OVERRIDE -V _PATCH_SEQ:M*PTHREAD* -V _PATCH_REAL_SEQ

300:pre-patch-PTHREAD-on 700:post-patch-PTHREAD-on
ask-license patch-message patch-depends do-patch post-patch post-patch-PTHREAD-on

can be changed:

$ make -V OPTIONS_TARGET_ORDER_OVERRIDE -V _PATCH_SEQ:M*PTHREAD* -V _PATCH_REAL_SEQ
690:post-patch-PTHREAD-on
300:pre-patch-PTHREAD-on 690:post-patch-PTHREAD-on
ask-license patch-message patch-depends do-patch post-patch-PTHREAD-on post-patch

[mat]

• Remove ::, not needed any more.
• Move the OPTIONS_TARGET_ORDER_OVERRIDE into a more generic TARGET_ORDER_OVERRIDE.

[mat]

• Make it work with fmake, and remove warning.

[mat]

• Simplify code here.

[mat]

• Document TARGET_ORDER_OVERRIDE.

[antoine]

Mk/bsd.port.mk

5660

Shouldn't this be ${_OPTIONS_package} ?

[mat]

Mk/bsd.port.mk

5660

it should.

[mat]

• Forgot to cleanup the _OPTIONS_*_package variables.

[mat]

• Change the way options targets are implemented, and add do- to the list