[MacPorts] #50246: CMake PortGroup : generate a file in ${workpath} containing the complete cmake invocation

[MacPorts]

#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