mk: allow changing the platform configuration source

[codyps]

Add the flag '--platform-cfg=path-to-dir' to configure location for platform
cfg.

Platform configuration (mk/cfg/*.mk) provides variables that some build
setups need to modify (for example, meta-rust:
https://github.com/meta-rust/meta-rust).

This allows build setups that need custom configuration to avoid
modifying the source tree & instead provide this configuration as part
of their internal "configure" build process.

[alexcrichton]

Thanks for the PR @jmesmon! Looking at this it feels... interesting! It seems a little odd providing a custom entry point to our build system because we don't really provide any sort of stability guarantees or anything about the makefiles, they'd probably have to change for releases here and there anyway to keep up.

That being said, though, this is something which I think rustbuild would be a great fit for? The configuration of pieces like a C compiler, CFLAGS, etc, should all be configurable through either config.toml or through environment variables using rustbuild. I wonder, would that be appropriate for your use case? We're trying to lessen the dependencies on the makefiles, so it'd be great to start adding features there rather than backporting to the makefiles.

[codyps]

It seems a little odd providing a custom entry point to our build system because we don't really provide any sort of stability guarantees or anything about the makefiles, they'd probably have to change for releases here and there anyway to keep up.

I don't really see it as that odd: the options in mk/cfg/*.mk are realistically a bunch of short-hand for some systems people build for often so they don't have to provide them themselves. We're just trying to get non-shortcut access.

It's absolutely correct that changes to files would be potentially needed with each compiler revision. I don't really see any issue there. A packager similarly needs to update dependencies, sources, build invocations, patches, etc. All of these things are things packagers (which meta-rust essentially is) expect to change occasionally.

There are essentially zero packages that provide guarantees about their build system's stability.

That being said, though, this is something which I think rustbuild would be a great fit for? The configuration of pieces like a C compiler, CFLAGS, etc, should all be configurable through either config.toml or through environment variables using rustbuild. I wonder, would that be appropriate for your use case? We're trying to lessen the dependencies on the makefiles, so it'd be great to start adding features there rather than backporting to the makefiles.

From rustbuild's readme:

Note: This build system is currently under active development and is not intended to be the primarily used one just yet. The makefiles are currently the ones that are still "guaranteed to work" as much as possible at least.

Should that be updated? Is rustbuild now the primary build system?

So you're saying that rustbuild probably can already do this via it's config files & env vars? Is there a stability guarantee or documentation for those? If not, having those things (which we've noted that mk/cfg/*.mk lacks) would be a good way to encourage rustbuild's use (I'd love needing to worry about one less thing).

In any case, wanting one to use rustbuild isn't a real reason to block adding a feature to makefiles.

When do we plan on removing the makefile build system from rust?

[alexcrichton]

Is rustbuild now the primary build system?

No, but we intend it to become so. As the author of rustbuild I'm recommending you use it for cross compilation scenarios as I know for a fact it works better than the makefiles. The config files and env vars are all stable interfaces, and no we don't have documentation beyond what's already there today (the build system is a work in progress). I do hope to add them soon to encourage rustbuild!

I would personally prefer to not add this feature, and if it's possible to get the meta-rust build working with rustbuild, that'd be great! I hope that by the end of the year the makefiles are gone.

[alexcrichton]

Closing due to inactivity, but if rustbuild ends up not panning out just let me know!

[codyps]

due to inactivity

I'm waiting on you to merge it. It's not inactive.

In meta-rust, we have a policy of trying to upstream changes we made to rustc, which is why I opened this. We're still using this mechanism, and we're unlikely to change off of it in the short term. If it's not accepted upstream, we'll still be using it (and simply carrying the patch locally). Obviously, we'd prefer avoiding that, though.

If you want to reject these changes, please say so explicitly.

Edit: figured it may help to give a bit more insight into why I'm not all that excited about switching to rustbuild:

• new snapshot (cargo) to depend on for rust-native to build (we're already depending on this to boostrap cargo-native, so not huge)
• another configuration file to generate, plus potential env vars (ie: switch to generating target.json & rustbuild.toml from target.json & target.mk)
• Not clear that rustbuild even supports our use case.

Now, if rustbuild did something like allow us to just generate target.json, that'd be great! And a perfect reason to switch to it. Right now, all we've got is "it's the new thing, eventually". That's not really convincing.

[alexcrichton]

Sorry I just personally go through periodically and close PRs that are N days old.

To be clear, yes, I would personally wish to avoid merging this upstream as it's not something I think we want to support ("stable" forms of mk/cfg/*.mk).

Would be good to have issues filed against rustbuild if it's not sufficient!