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

Do not clone common arguments multiple times #51

Open
CohenArthur opened this issue Jul 29, 2021 · 0 comments
Open

Do not clone common arguments multiple times #51

CohenArthur opened this issue Jul 29, 2021 · 0 comments
Labels
enhancement New feature or request priority:high High priority issue. Essential to the project's operation

Comments

@CohenArthur
Copy link
Member

CohenArthur commented Jul 29, 2021

IIUC most of the Options are common to all gccrs invocations. So

rustc --crate-type=dyn --crate-type=bin src/<file>.rs --other-flag-1 --other-flag-2

becomes

gccrs src/<file>.rs --converted-other-flag-1 --converted-other-flag-2  # bin
gccrs -shared src/<file>.rs -o libfile.so --converted-other-flag-1 --converted-other-flag-2  # shared lib

where --converted-other-flag-1 --converted-other-flag-2 are common to all invocations. So why not only store them once?

pub struct OptionsCollection {
    common_args: Vec<Arg>,
    crate_types: Vec<CrateType>,
    ... // Other fields that require multiple gccrs invocations, if any
}

I think that would make things way cleaner and would avoid saving the common options and input+output file name N times.

Maybe even:

pub struct Args {
    input_files: Vec<String/PathBuf>,
    output_file: String/PathBuf,
    common_args: Vec<Arg>,
    crate_types: Vec<CrateType>,
    ... // Other fields that require multiple gccrs invocations, if any
}

And only once you generate the gccrs commands, you will build the whole Vec<Vec> argument matrix.

Originally posted by @flip1995 in #47 (comment)

@CohenArthur CohenArthur added the enhancement New feature or request label Jul 29, 2021
@CohenArthur CohenArthur added the priority:high High priority issue. Essential to the project's operation label Aug 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request priority:high High priority issue. Essential to the project's operation
Projects
None yet
Development

No branches or pull requests

1 participant