Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why we still use Makefile? #437

Open
yangfh2004 opened this issue Jun 13, 2023 · 2 comments
Open

Why we still use Makefile? #437

yangfh2004 opened this issue Jun 13, 2023 · 2 comments

Comments

@yangfh2004
Copy link

I think much pre-processing in the Makefile can be done with "build.rs", why don't we use most of the current Cargo tool instead of using the ancient Make toolchain? Maybe this is a stupid question, but which step forces us to use "make" instead of any other modern build system? I wish we can reduce the size of Makefile and use as much as possible with "build.rs" in the v2.0 if we can't eliminate the Makefile.

@hu6360567
Copy link

hu6360567 commented Nov 7, 2023

Hi, I'm trying to replace the long Makefile with a building crate for v2 branch, so that I can maintain my TEE code in cargo workspace with a large code base.

The ideal workflow is to use build.rs to generate/compile edl files and link into the rust crate, and finally, use a separate script to sign the dynamic so (since cargo not support post-build script), just like below,

  1. declare metadata in Cargo.toml
  2. build.rs parse metadata, generate, compile and link edl wrapper codes into the rust crate for both trusted and untrusted
  3. sign the enclave.

Cargo build command with profile once can build all rust code and an additional operation to sign the enclave.
But the progress seems not so well.

Current progress:

  1. use a template Makefile to dump variables generated from buildenv.mk and other general variables in sample code.

  2. parse metadata of intel/teaclave sgx sdk; edl path; build_std options and sgx_mode/debug based on the profile

  3. compile_untrusted is used to generated and compile edl untrusted sources, and declare rust link args, so that the edl can be linked into the crate.

  4. compile_trust works like compile_trusted but for enclave, which is different from current Makefile.

    • the normal workflow of Makefile is compiling the trusted "entry" code into a static lib with its dependencies, and use g++ to link enclave_t.o with it into a dynamic lib.
    • my solution is to use compile_trust in a build.rs for a 'cdylib' crate, so that it can be directly linked into an dynamic library to be signed.

So far so good, but the problem came out with "BUILD_STD": build.rs cannot set sysroot and target. Specifying sysroot and target needs to be done out of build.rs (although I can compile sysroot inside of build.rs).
It is said, before building "trusted" codes, sysroot needs to be compiled first, and push the flags into cargo commands. "cargo build" once is not able to generate all output of rust code.

it needs some other scripting system to do that, then not much different from current Makefile.

TODO:
I may try with cargo-make, hope it can simplify the building workflow and make it more easy to extend.

@yangfh2004
Copy link
Author

Thanks a lot, I think we could somehow simplify the Makefile with using more build.rs and other modern Cargo features.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants