apache / incubator-teaclave-sgx-sdk

Apache Teaclave (incubating) SGX SDK helps developers to write Intel SGX applications in the Rust programming language, and also known as Rust SGX SDK.
https://teaclave.apache.org
Apache License 2.0
1.18k stars 265 forks source link

Why we still use Makefile? #437

Open yangfh2004 opened 1 year ago

yangfh2004 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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