#50246: CMake PortGroup : generate a file in ${workpath} containing the complete cmake invocation --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | --------------------------+-------------------------------- Changes (by mf2k@…): * version: 2.3.4 => * type: request => enhancement * port: cmake => Comment: Note that a "request" ticket type is only for requesting a new port. -- Ticket URL: <https://trac.macports.org/ticket/50246#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X

#50246: CMake PortGroup : generate a file in ${workpath} containing the complete cmake invocation --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by rjvbertin@…): I don't know about doing this in cmake, but I ought to be able to design a patch one of these days. Do you think the environment should be dumped to that file too? -- Ticket URL: <https://trac.macports.org/ticket/50246#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X

#50246: CMake PortGroup : generate a file in ${workpath} containing the complete cmake invocation --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by rjvbertin@…): Among the ports that I update frequently there are only few which I update in the regular, one-shot fashion. Logfiles don't only get lost after an update, but by each consecutive step if you split the process, and there are valid reasons for doing so even if you're not developing a port. When I say "developing a port", I mean not just the portfile, but also the software it bundles. That's what I'm also doing with my Qt and KF5 ports, so yes, I do lots of incremental builds. MacPorts' de/activate feature comes in very handy in that context. I'm pretty sure I'm not the only one doing this, and it's why I wrote those utilities I submitted here a while back (port-redo-install-phase, port-edit-statefile, ...) To answer your question: yes, it would make sense to implement this in "base". I've suggested the idea several months ago already, but it wasn't picked up. I've also coined the idea upstream, to store the full command in the CMakeCache header, but I guess they feel that's not necessary. The reason I now requested it for cmake is twofold: 1- cmake commands tend to get much more complicated once you do need arguments; certainly much less readable 2- I've never seen an IDE that needs to know the cmake command because it'll call cmake as part of its project-parsing step. Storing the command for the build step is probably not of much use (tends to be really simple), for the destroot probably a bit more. I've already looked how to reconstruct it in order to do a partial destroot manually, of a very big port on a slow host. In fact, the destroot of Qt5 must take somewhere between 2 and 5 minutes on my MBP, so yeah, anything that makes it easier doing partials would be appreciated - but that's another topic altogether. -- Ticket URL: <https://trac.macports.org/ticket/50246#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X

#50246: CMake PortGroup : generate a file in ${workpath} containing the complete cmake invocation --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by rjvbertin@…):

I'd love to see this feature in base, somehow: a single command including environment variables for how to do the configure stage.

Do you mean a way to call `port configure` repeatedly, ignoring when saved state says configure has already been done?

cmake does actually store it's original command line internal to the build (somewhere; I don't remember)

Part of the info is stored in the "preamble" (commented out lines) of CMakeCache.txt, the rest is based on what is stored in CMakeCache.txt. Presumably, that file is loaded to pre-initialise variables that could also be specified on the command line, meaning you don't need to do that in a repeat invocation. Of course that doesn't fly during the 1st invocation, and also presumes that repeat invocations (as could be done by an IDE) do not set arguments of their own. And what Michael said about the environment. -- Ticket URL: <https://trac.macports.org/ticket/50246#comment:7> MacPorts <https://www.macports.org/> Ports system for OS X

#50246: CMake PortGroup : generate a file in ${workpath} containing the complete cmake invocation --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by rjvbertin@…): Sounds like the sort of thing I do all the time too. Do a search for port- redo-install-phase here on trac, it should lead you to the current version in my repo. It handles removing specific entries from the state file, but also updates its checksum so you stand less risk of losing the entire build dir. It is rarely required to remove the entire build.dir in my experience. Most of the time a cmake rerun will suffice; sometimes you'd better remove CMakeCache.txt first. The port-redo-install-phase `-configure` vs. `-configure-all` options implement those 2 approaches. There's also `port-active-variants` which helps not having to re-determine the current variants every time ;) {{{

port-redo-install-phase -configure|-configure-all [-build] [-destroot] foo port -nvok {configure,build,destroot} `port-active-variants -echo foo` configure.optflags="..." }}}

-n : don't touch anything else; -o : reduncant after port-redo* but let's take no risks; -k : idem, don't risk forgetting this one when editing the last command to do an install / upgrade --force ;) And sometimes I do a `port-edit-state foo` if I want to add or remove a variant. The only thing that still surprises me in all that is how long it took before I went ahead and wrote those utilities... -- Ticket URL: <https://trac.macports.org/ticket/50246#comment:9> MacPorts <https://www.macports.org/> Ports system for OS X