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

[Nagaev Boris]

On Thu, Dec 7, 2017 at 3:55 AM, Tony Theodore <address@hidden> wrote:
>
> 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
>
>

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

-- 
Best regards,
Boris Nagaev