-
-
Notifications
You must be signed in to change notification settings - Fork 79
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
feat(compilation): compilation directory depends on more cli flags #270
base: main
Are you sure you want to change the base?
Conversation
on optimization level, include dirs and the macro defines
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can see why you were asking me questions about these two directories. Everything we have in there is confusing. 😂
This is what we want, going forward:
- Compiled object files ALWAYS are written to the binary cache dir; there is no option to change that
- The CLI option is for changing where the final executable is stored; I think we should just rename this to
-o <file>
for the CLI command which compiles binaries. We don't need to specify a dir or anything.
I think that means we can rename output_dir
in RT ctx to binary_cache_dir
, to be super clear of the intention. Then we can remove the --output-dir
flag altogether. Later, when we support compiling executables, we can add in the -o <file>
flag for that command.
That makes sense. Now that we do not have |
, binary_cache_dir{ fmt::format( | ||
"{}/{}", | ||
util::binary_cache_dir(opts.optimization_level, opts.include_dirs, opts.define_macros), | ||
"classes") } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for classes
at all. That's a carry-over from the JVM.
return res = fmt::format("{}/{}", user_cache_dir(), binary_version()); | ||
return res = fmt::format("{}/{}", | ||
user_cache_dir(), | ||
binary_version(optimization_level, includes, defines)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I was wrong, Saket. This is not going to work. If two separate projects both have ns a
, with different code, then compiling one project first, then going to compile the other project could result in loading the first project's a
when you go to compile the second.
This could work fine for dependencies from maven, but we don't have a good way to distinguish them from project sources right now. To mitigate this, let's put the binary cache dir in target/<binary version>
, relative to the current directory. This is what leiningen does. So we should just be able to replace user_cache_dir
here with "target"
.
on optimization level, include dirs and the macro defines
Related to #139