Hi Michael,
The project I'm building creates a configuration script when cmake is
executed based on the path where the build happens. So when the whole build
directory is moved from ${worksrcpath} to a new location it fails to
configure.
BTW I think I set the cmake.build_dir
to
Just remember that "${destroot}" will not exist until the "destroot" phase
unless it is created in the Portfile script. If you need a different build
directory than that provided by the CMake PG, then you can in the Portfile
create some other directory & my advice would be to place it in the
Hi Fred - My thoughts follow. This will likely be my only reply to your post or
reply here since it's heading toward being off-topic & honestly comes down much
more to personal preference than any technical requirement; it's more along the
lines of a "culture war" such as "Mac versus PC",
Um. Good to know that.
I think what I would like to do can be achieved by smartly using
${destroot} to deploy a new build dir and move the files to where I would
like. In this case the build happens in the work dir and will eventually
end up in where I want it to be.
As I suggested in a
On Thu, 2 May 2019, Michael Dickens wrote:
Why not leave the build directory alone & let the cmake 1.1 PG handle it? Most
CMake-based ports can handle out-of-source
building these days, and that's the default for the cmake 1.1 PG, and the
default setting here should work for the vast
Hi all macports fans,
I'm recently learning to do some small modifications and enhancements on an
existing portfile. One way I found that would solve my problem was to
modify the build dir of cmake. (The PortGroup == cmake 1.1).
I tried to set cmake.build_dir to
On Wed, May 01, 2019 at 12:30:18PM +, Zero King wrote:
On Wed, May 01, 2019 at 10:19:53AM +0100, Chris Jones wrote:
Hi,
I've noticed over the last day or so the azure checks in PRs are
consistently failing, e.g.
https://github.com/macports/macports-ports/pull/4225
