Introducing some "global" build out-of-source variable

[Mojca Miklavec]

On 24 March 2018 at 02:52, Ryan Schmidt wrote:
> On Mar 23, 2018, at 15:10, Mojca Miklavec wrote:
>
>> In the absence of any PortGroup implementing the build system, this
>> should make sure that autotools-based ports would properly build out
>> of source without changing anything else.
>
> I didn't think that autotools in general supported out-of-source builds. Certainly individual projects might support it, but I got the impression that this was much more of an opt-in situation with autotools than it is with cmake where almost all cmake-using projects work with out-of-source builds.

I'm pretty sure that many autotools-based projects fail to work
correctly when built out of source.
Than said, it easy enough to write a cmake-based project that will
also fail and many do, it's just a matter of the developer's idea of
testing this and fixing problems.

I'm certainly not suggesting to make this build mode default, only to
offer some generic/universal interface, so that ports using any given
build system could change the same option instead of reinventing the
wheel in each build system (even if each build systems needs to
implement it in its own way).

> I guess we could add build.out_of_source to base, set it up in base so that it works for those autotools projects that support out-of-source builds, and leave it up to ports to enable it if desired, and for build system portgroups to override with behavior that works for them.

Yes, that would be exactly my suggestion.

Another question just popped up in one of the tickets: "When does base
create ${configure.dir} and ${build.dir}?" I believe the answer is
never, but I believe half of the problem could probably be solved if
all a port needed to do was

    configure.dir ${workpath}/build

and then build.dir would also point to ${configure.dir} automatically
and both would be created automatically when not existing. (There
might be undesired side effects, I don't know, at this point I don't
want to claim that this is necessarily a good idea, just a thought.)

One particular port tried to use

    configure.dir ${workpath}/build
    build.dir ${configure.dir}
    pre-configure {
        file mkdir ${configure.dir}
    }

which failed because the PortGroup was already expecting
${configure.dir} to exist as it did something else with it in its own
pre-configure step (which gets executed before the one specified in
the port), so the workaround was to use the pretty counter-intuitive

    post-patch {
        file mkdir ...
    }

> This all presumes that out-of-source builds are useful. I'm never sure if they are. Some people sure seem to like them, but I thought their primary use was when you want to cross-compile for different systems, each to their own build directory, or when you are doing development in a long-running git clone of the source and you want to keep it clean of build artifacts. MacPorts is building only for one system, and always starts from a clean build directory because it always starts by extracting the source, so these benefits don't seem to apply to MacPorts.

OK, I totally agree with that. In the context of MacPorts it is not
nearly as useful as it is outside (where I nowadays use it almost
exclusively, if nothing else because I would fetch the source once and
if I run ./configure && make in the source, I cannot ever rely that
"make clean" would do its job, but I usually also try to run different
flags etc.; if it's git, it's at least easy to clean, if it's a
tarball ... good luck, other than deleting it and extracting it
again).

But some build systems require it, some port maintainers might simply
wish to test if the software works correctly with it in order to
report upstream, I don't know what our muniversal PG is doing ...

Mojca