[MacPorts] #56377: Additions to the cargo PG for all cases

[MacPorts]

#56377: Additions to the cargo PG for all cases
-------------------------------------------------+-------------------------
  Reporter:  MarcusCalhoun-Lopez                 |      Owner:  (none)
      Type:  enhancement                         |     Status:  new
  Priority:  Normal                              |  Milestone:
 Component:  ports                               |    Version:
Resolution:                                      |   Keywords:
      Port:  ripgrep fd mesalink ​racer librsvg  |
  cargo                                          |
-------------------------------------------------+-------------------------

Comment (by raimue):

 Hm, I always thought the main use of the cargo port group was to run a
 build with cargo. I am not sure the proposed way would work, because the
 default of `yes` would always override `build.cmd`...?

 I guess the only way to make that work would be a default value of `no`
 and force all ports to use `cargo.direct_call yes`. However, that would be
 not consistent with other port groups, such as those for cmake or meson,
 that all just override the commands by default. I also do not think
 `direct_call` is an intuitive name.

 How about we split the port group in two parts? Port group `cargo_fetch`
 would handle the `cargo.crates` options for fetching, but only `PortGroup
 cargo` would also override the build commands. The latter would include
 the former. Then mesalink and librsvg would only use `PortGroup
 cargo_fetch`.

 ----

 I am not sure I understand the problem that `cargo.worksrcdir_crates` is
 supposed to solve. Why is the config file causing a problem? I assume
 librsvg does not need any external crates? Why does librsvg need the cargo
 port group at all, if it is neither fetching crates nor using the build
 system commands...?

 We could choose not to create `cargo.home` if both `cargo.crates` and
 `cargo.crates_github` are empty. Then we would not even need an extra
 setting for this.

 ----

 Could we solve the problem of the target directory with
 `CARGO_BUILD_TARGET` by setting `OUT_DIR`? Most builds seem to respect
 that in the environment.

 ----

 Fixing muniversal to support `destroot {}` would be one possible solution.
 However, using muniversal seems overkill anyway, as it seems to do a lot
 of stuff that is not necessary for cargo at all. As you wrote, cargo
 already uses different output directories per build architecture, so all
 that would be necessary is to execute the `cargo build` command multiple
 times, then merge the binaries/libraries. As all binary files seem to end
 up in a known place, that seems much simpler than what muniversal
 implements.

 However, this will probably not help with librsvg, which was probably your
 main use case for this...

 It could be an alternative for +universal builds, there is also
 [https://github.com/TimNN/cargo-lipo cargo-lipo]. I have no experience
 with it, but it also seems to provide the functionality. Although it is
 meant to be used for iOS builds, though.

 ----

 The way `destroot {}` is implemented right now is largely due to an
 [https://github.com/rust-lang/cargo/issues/2729 upstream issue], as cargo
 cannot handle additional files such as man pages. Otherwise I would just
 have set `destroot.cmd cargo install`. Therefore my solution was to force
 Portfile authors to write their own `destroot {}` phase that installs all
 files that can be installed. The destroot phase in the cargo port group
 was intended to remind Portfile authors to take a closer look which files
 should be installed.

 ----

 I specifically left `build.target` empty. As I understand cargo, that
 would be the place to specify `--all`, `--bin <binary>`, `--libs`, or
 similar arguments, as this is what cargo calls a "build target". The
 command we want to run is in fact always `cargo build`.

 With a custom cargo, I would just change that to `build.cmd
 .../path/to/cargo build`.

-- 
Ticket URL: <https://trac.macports.org/ticket/56377#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS