Re: Errors when changing cmake build directory
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 ${destroot}/${prefix}/share/abc/abc${abc.version}/
in the very beginning and the build happened in
so ${destroot} was available in the very beginning of the port definition I
guess.
/opt/local/var/macports/build/_Users_frankliuao_ports_science_abc/abc4.10.5/work/destroot/opt/local/share/abc/abc4.10.5/
I also need some workaround for this problem. LOL. Probably manually
generate a new script...
Best,
Ao
On Thu, May 2, 2019 at 3:17 PM Michael Dickens
wrote:
> 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 top
> level "${worksrcpath}" directory -- which is where the "build" directory is
> placed. Not sure why one would need this, but maybe there's a use-case I'm
> not imagining. Good luck! - MLD
>
> On Thu, May 2, 2019, at 3:20 PM, Ao Liu wrote:
>
> 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 recent ticket - it would be nice for the website to
> explain the ${destroot} variable in more details. Helps the developer to
> build powerful stuff.
>
> Thanks for the replies folks!
> Ao
>
>
>
Re: Errors when changing cmake build directory
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 top level
"${worksrcpath}" directory -- which is where the "build" directory is placed.
Not sure why one would need this, but maybe there's a use-case I'm not
imagining. Good luck! - MLD
On Thu, May 2, 2019, at 3:20 PM, Ao Liu wrote:
> 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 recent ticket - it would be nice for the website to
> explain the ${destroot} variable in more details. Helps the developer to
> build powerful stuff.
>
> Thanks for the replies folks!
> Ao
Re: Errors when changing cmake build directory
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", "iPhone versus Android" and the like. Each side has benefits and drawbacks; neither side is entirely in the right nor in the wrong. There is very little point in flaming such wars. (1) CMake and in-source versus out-of-source: In my opinion you're not correct: CMake itself is build-location agnostic; it does not default to in-source builds. Individual projects may choose to provide just in-source building, but in my experience the vast majority of projects that use CMake for building can be built in-source or out-of-source. When one issues the "cmake" command, the final argument is the directory containing the top-level CMakeLists.txt file in the source to be built; this directory can be relative (e.g., ".", or ".."), or absolute (e.g., "/path/to/top/level/cmakelist_txt/dir/"). Modern and recent CMake itself is agnostic as to whether one builds in-source or out-of-source; such CMake has no default either way, whether explicit or implicit. NOTE: I do think that -very old- CMake maybe did require in-source builds, but we're talking version 1 or maybe early version 2 -- many years ago! In my many years of using CMake (since sometime in mid-version 2), CMake has worked for both in-source and out-of-source builds quite robustly; the CMake scripting required to make it work both ways is nominally different than requiring in-source builds. Some projects wrote their original CMake scripts with in-source in mind, and have never bothered to update their CMake scripts to allow for out-of-source builds. The vast majority of projects that I've ever heard of or experienced that use CMake work with out-of-source builds, whether because the CMake scripts were originally written in the generic build location style, or because they were fixed to allow building either way. (2) cmake PG settings: The default cmake 1.1 PG settings are for out-of-source builds: yes! But, one can in any individual Portfile change this setting quite easily or just use the cmake 1.0 PG, which defaults to in-source builds (with the option of doing out-of-source builds if set specifically in the Portfile using this PG). v1.1 is more robust overall, but v1.0 is probably plenty sufficient for many ports. (3) benefit of cmake out-of-source builds: The benefit of out-of-source builds is negligible in the MP environment: true if you're just an end-user! I tend to believe that most MP users just want MP to work, whether compiling from source or installing via a pre-built archive. CMake out-of-source builds are meaningless from this perspective. That said, to get ports to the point where they install and work robustly, the out-of-source build is a convenience for developers who are doing the work to get ports to this point. I have scripts that allow me to manipulate project source code as provided via "port work", e.g., to create a top-level temporary GIT repo so that I can easily get "diff"s to what's changed & then create a patch for those changes; I can tweak the build scripts and actual code to be compiled until it works in the ways I deem robust. Having an out-of-source build means I can just "rm -rf" the build directory and restart the build from scratch. One can, of course, "make clean" whether building in-source or out-of-source but that may or not do the trick depending on how well the CMake scripts keep track of build or modified files; "rm -rf" is -very- reliable at cleaning the build! --- Summary: CMake out-of-source builds, at least in my opinion and experience, are not difficult to have well implemented from the project developer's perspective, and they benefit us developers trying to make ports as robust as possible. I wouldn't want it any other way! Cheers! - MLD On Thu, May 2, 2019, at 3:00 PM, Fred Wright wrote: > But note that CMake's own default is *not* to build out-of-source (with > extra steps required when you want to), and not all projects build > correctly out-of-source. So the PG default behavior is inconsistent with > CMake itself, as well as just plain not working in some cases, and the > poor discoverability of the option to change that (as well as the change > in the default from 1.0) makes that default even more undesirable. > > Also note that the benefit of out-of-source builds is negligible in the > MacPorts environment, anyway. > > Fred Wright
Re: Errors when changing cmake build directory
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 recent ticket - it would be nice for the website to
explain the ${destroot} variable in more details. Helps the developer to
build powerful stuff.
Thanks for the replies folks!
Ao
On Thu, May 2, 2019 at 11:49 AM 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 majority of cmake-based ports.
>
> To your query: You shouldn't try to write to or generate files outside the
> ${worksrcdir} (or ${worksrcpath}); all configuring, building, installing,
> patching, etc must be done within the port's build path.
>
> Hope this is useful! - MLD
>
> On Thu, May 2, 2019, at 12:40 PM, Ao Liu wrote:
>
> 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 ${prefix}/share/abc/abc${abc.version}/
>
> But it always throws an error and I believe it was because cmake can not
> write to the above directory. I tried to chown the directory to macports,
> still doesn't work.
>
> Any guidance on how to customize the CMake build directory? Thanks folks!
>
> :info:configure CMake Error at
> /opt/local/share/cmake-3.14/Modules/CMakeDetermineSystem.cmake:173 (file):
>
> :info:configure file failed to open for writing (No such file or
> directory):
>
> :info:configure
> /opt/local/share/abc/abc4.10.5/CMakeFiles/CMakeOutput.log
>
> ...
>
> ...
>
> ...(similar CMake errors)
>
>
>
Re: Errors when changing cmake build directory
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 majority of cmake-based ports. But note that CMake's own default is *not* to build out-of-source (with extra steps required when you want to), and not all projects build correctly out-of-source. So the PG default behavior is inconsistent with CMake itself, as well as just plain not working in some cases, and the poor discoverability of the option to change that (as well as the change in the default from 1.0) makes that default even more undesirable. Also note that the benefit of out-of-source builds is negligible in the MacPorts environment, anyway. Fred Wright
Errors when changing cmake build directory
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 ${prefix}/share/abc/abc${abc.version}/
But it always throws an error and I believe it was because cmake can not
write to the above directory. I tried to chown the directory to macports,
still doesn't work.
Any guidance on how to customize the CMake build directory? Thanks folks!
:info:configure CMake Error at
/opt/local/share/cmake-3.14/Modules/CMakeDetermineSystem.cmake:173 (file):
:info:configure file failed to open for writing (No such file or
directory):
:info:configure
/opt/local/share/abc/abc4.10.5/CMakeFiles/CMakeOutput.log
...
...
...(similar CMake errors)
Re: azure pipelines consistently failing
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 https://github.com/macports/macports-ports/pull/4224 https://github.com/macports/macports-ports/pull/4220 I don't believe the problem is with the ports, but something is up with the framework itself. The failures are always very similar. Could someone who knows how this stuff works take a look ? Looks like Azure Pipelines service in West Europe region is degraded: https://status.dev.azure.com/_event/117874362. We forced a re-download of the corrupted file and propagated it across the impacted pools, and this has caused the machines to work properly now. The issue impacted pipelines for some MacOS pools in the West Europe region. The issue started at 2019-04-30 14:45 UTC and was resolved at 2019-05-01 12:20 UTC Is it working now? Not sure if it's related to build failures though. cheers Chris -- Zero -- Zero smime.p7s Description: S/MIME cryptographic signature
