m4sterchain commented on code in PR #245: URL: https://github.com/apache/teaclave-trustzone-sdk/pull/245#discussion_r2477590499
########## cargo-optee/src/main.rs: ########## @@ -0,0 +1,158 @@ +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +use clap::{Parser, Subcommand}; +use std::env; +use std::path::PathBuf; +use std::process::abort; + +mod ca_builder; +mod common; +mod ta_builder; + +use common::Arch; + +#[derive(Debug, Parser)] +#[clap(version = env!("CARGO_PKG_VERSION"))] +#[clap(about = "Build tool for OP-TEE Rust projects")] +pub(crate) struct Cli { + #[clap(subcommand)] + cmd: Command, +} + +#[derive(Debug, Parser)] +struct BuildTypeCommonOptions { + /// Path to the app directory (default: current directory) + #[arg(long = "path", default_value = ".")] + path: PathBuf, + + /// Target architecture: aarch64 or arm (default: aarch64) + #[arg(long = "arch", default_value = "aarch64")] + arch: Arch, + + /// Path to the UUID file (default: ../uuid.txt) + #[arg(long = "uuid_path", default_value = "../uuid.txt")] + uuid_path: PathBuf, + + /// Build in debug mode (default is release) + #[arg(long = "debug")] + debug: bool, +} + +#[derive(Debug, Subcommand)] +enum BuildCommand { + /// Build a Trusted Application + TA { + /// Enable std feature for the TA + #[arg(long = "std")] + std: bool, + + /// Path to the TA dev kit directory (mandatory) + #[arg(long = "ta_dev_kit_dir", required = true)] + ta_dev_kit_dir: PathBuf, + + /// Path to the TA signing key (default: $(TA_DEV_KIT_DIR)/keys/default_ta.pem) + #[arg(long = "signing_key")] + signing_key: Option<PathBuf>, + + #[command(flatten)] + common: BuildTypeCommonOptions, + }, + /// Build a Client Application (Host) + CA { + /// Path to the OP-TEE client export directory (mandatory) + #[arg(long = "optee_client_export", required = true)] + optee_client_export: PathBuf, + + #[command(flatten)] + common: BuildTypeCommonOptions, + }, +} + +#[derive(Debug, Subcommand)] +enum Command { Review Comment: `cargo_metadata` retrieves meta info based on `cargo.toml` and command-line options in a programatic way, which does not mean convert to `cargo build --features std`. It is designated to used from within a cargo-* executable. https://crates.io/crates/cargo_metadata Here is a more concrete example to illustrate the difference. - `cargo-optee build ta --std` means no matter what default feature developer defines in the Cargo.toml, the customized toolchain will build in using std library (new convention is introduced by cargo-optee). - `cargo optee build` (with other cargo compatible flags) means the the customized toolchain will respect what feature the developer enables in the Cargo.toml (std/no-std) and automatically handles internally (select xargo to build stdlib or not) based on the active feature. `Any reasons on why we should follow seamless interface principle?` There’s no strict requirement to maintain full consistency with Cargo’s original command-line parameters. However, I am just wondering if our goal should be to make OP-TEE development feel like a natural extension of the standard Cargo experience — a design I believe is achievable for our current use cases. To realize this, we can learn from existing customized toolchains, e.g. both tools you mentioned also leverage `cargo_metadata` to retrieve project setup information. I will end this conversation here, as I believe I’ve explained my points clearly and don’t want to spend more time on further debate. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
