#53284 closed defect (invalid)
shouldn't pre-configure be skipped when `use_configure no`?
| Reported by: | RJVB (René Bertin) | Owned by: | |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | base | Version: | |
| Keywords: | Cc: | ||
| Port: |
Description
It's all in the title: shouldn't pre-configure (and post-configure) blocks be skipped when use_configure no? They should be irrelevant, and could cause undesirable side-effects.
It may sound surprising that you'd run into the question. In practice it is in fact perfectly possible when a Portfile has one or more stub subports, either because the file provides a pre-configure itself for the main port (subports), or because a PortGroup does (e.g. the qmake5 and cmake-1.1 PGs).
Change History (2)
comment:1 Changed 7 years ago by jmroot (Joshua Root)
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:2 Changed 7 years ago by RJVB (René Bertin)
I see you point, but is it really valid? Shouldn't alternative configuration systems ideally redefine configure.cmd and provide their own configure if they have to? The way I interpret use_configure no is that it turns off the configuration step altogether because it's unneeded or unwanted, for projects that come with a preexisting Makefile, use xcodebuild or don't build anything.
It's been ages since I used xmkmf but IIRC it stands for "X Make Makefile" and is/was a precursor to autoconf and cmake etc. So you'd do
> xmkmf > make
Is the autoreconf setting respected when you set use_configure no?
No, it shouldn't. That setting doesn't mean the configure phase disappears, it means it won't run
./configure(or whatever configure.cmd). You could still be using an alternate configuration system like xmkmf.