[Mingw-cross-env-list] Improve dependency metadata specification

[Tony Theodore]

Hi All,

I'd like to make some improvements to the way we handle dependencies
for the core toolchain and native libraries/tools we build.

At the moment, we use target dependencies so all native builds occur
before any cross-targets. This causes various issues such as `gcc`
requiring `cmake` or `binutils` requiring `pkgconf`.

Another problem is that we don't have a way of determining if a package
has an empty build rule because it's explicitly disabled or if it's a
source-only package.

I've raised a PR[1] for this which introduces:
- explicit cross-target deps (i.e. `gcc` depends on $(BUILD)~gmp)
- optional order-only deps which won't trigger rebuilds
- virtual toolchain package `cc` which gathers `gcc`, `pkgconf`, and
any general native tools
- autotools/cmake are automatic order-only deps for those packages
that invoke them
- better handling of disabled, source-only, and meta pkgs in both
build status output, build-matrix[2], and input for `build-pkg`

The only issue I can see is if someone is relying on implied
dependencies that would currently be built with `gcc` alone (a message
will be printed in this case). Building any other packages will cause
any required packages to be built as normal.

`make gcc` is probably the longest-standing convention - we'll never
need to change it again so I'm hoping these changes won't cause any
issues or undue confusion.

Cheers,

Tony


[1] https://github.com/mxe/mxe/pull/1990
[2] https://deploy-preview-1990--mxe.netlify.com/build-matrix.html

[Nagaev Boris]

Post by Tony Theodore
Hi All,
I'd like to make some improvements to the way we handle dependencies
for the core toolchain and native libraries/tools we build.
At the moment, we use target dependencies so all native builds occur
before any cross-targets. This causes various issues such as `gcc`
requiring `cmake` or `binutils` requiring `pkgconf`.
Another problem is that we don't have a way of determining if a package
has an empty build rule because it's explicitly disabled or if it's a
source-only package.
- explicit cross-target deps (i.e. `gcc` depends on $(BUILD)~gmp)
- optional order-only deps which won't trigger rebuilds
- virtual toolchain package `cc` which gathers `gcc`, `pkgconf`, and
any general native tools
- autotools/cmake are automatic order-only deps for those packages
that invoke them
- better handling of disabled, source-only, and meta pkgs in both
build status output, build-matrix[2], and input for `build-pkg`
The only issue I can see is if someone is relying on implied
dependencies that would currently be built with `gcc` alone (a message
will be printed in this case). Building any other packages will cause
any required packages to be built as normal.
`make gcc` is probably the longest-standing convention - we'll never
need to change it again so I'm hoping these changes won't cause any
issues or undue confusion.
Cheers,
Tony
[1] https://github.com/mxe/mxe/pull/1990
[2] https://deploy-preview-1990--mxe.netlify.com/build-matrix.html

Hi Tony

Can you elaborate on "optional order-only deps which won't trigger
rebuilds", please? If A order-only depends on B, what the following
commands do?

1. Just building A.
$ make A

2. Building A, then modifying B, then building A again:
$ make A
$ touch src/B.mk
$ make A

[Tony Theodore]

Hi Boris,

Post by Nagaev Boris
Can you elaborate on "optional order-only deps which won't trigger
rebuilds", please? If A order-only depends on B, what the following
commands do?
1. Just building A.
$ make A

This will build B before A

Post by Nagaev Boris
$ make A
$ touch src/B.mk
$ make A

This will rebuild B but not A.

Order-only deps[1] are useful for build tools like cmake and pkgconf, changes
to these should not trigger rebuilds in the packages that use them, only
library deps should cause a rebuild.

Updates to these packages will be tested against the entire set of packages
and if a user pulls those updates and there are no changed libraries in the
subset of packages they are building, then no rebuilding is required. If the
libraries have changed, then they will be rebuilt as normal with the newer
versions of tools.

Hope that makes sense.

Cheers,

Tony


[1] https://www.gnu.org/software/make/manual/make.html#Prerequisite-Types