[apache/incubator-teaclave-sgx-sdk] Why we still use Makefile? (Issue #437)

[Fanghao Yang <no...@github.com.INVALID>]

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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/437
You are receiving this because you are subscribed to this thread.

Message ID: <ap...@github.com>

Re: [apache/incubator-teaclave-sgx-sdk] Why we still use Makefile? (Issue #437)

[Fanghao Yang <no...@github.com.INVALID>]

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

-- 
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/437#issuecomment-1798593518
You are receiving this because you are subscribed to this thread.

Message ID: <ap...@github.com>

Re: [apache/incubator-teaclave-sgx-sdk] Why we still use Makefile? (Issue #437)

[Wenbo Hu <no...@github.com.INVALID>]

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 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.
5. parse metadata of intel/teaclave sgx sdk; edl path;  build_std options and sgx_mode/debug based on the profile
6. `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.
7. `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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/437#issuecomment-1798296271
You are receiving this because you are subscribed to this thread.

Message ID: <ap...@github.com>