-
Notifications
You must be signed in to change notification settings - Fork 5
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
sinol-make file structure and run command #1
Conversation
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.
Just approving, if you would like to have normal review, please let me know.
@twalen while I plan to review the project in the context of added functionality, decisions and etc, I don't have much experience with Python. I would appreciate if you could make reviews 😄 |
That depends on the existing issues with |
Let's try to implement then in separate PRs. |
I think that |
You mean that compiling without makefiles should be in seperate PR? There is some unfinished code for compiling here |
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.
Overall looks good!
From what I remember, Marek Sokołowski might be a good person to ask about MacOS stuff. |
Yes, I prefer to have separate functionalities in separate PRs (but you don't have to split this PR). Otherwise reviewing becomes a mess and PRs are left open for eternity. |
Also, which license do we want to use? |
The same as |
9d1b07a I removed global config and finished compilation without makefiles |
Nice! I'll try to review it today. |
add --oiejq_path flag for run command replace asserts with proper error messages
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.
Just some small comments. I think we're going to merge this PR as soon as they are resolved 🚀
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.
Looks good, I'm giving approve so that you can merge (if you think that the TODO comments are not enough and you'll forget about changing something, you can create an issue). Though, before merging, please resolve the last open comment.
for program in self.get_programs(None): | ||
ext = os.path.splitext(program)[1] | ||
if ext == '.c' and args.c_compiler_path is None: | ||
if sys.platform == 'darwin': | ||
print(util.bold(util.color_red('Couldn\'t find a C compiler. Tried gcc-{9,10,11,12}. Try specifying a compiler with --c_compiler_path.'))) | ||
exit(1) | ||
else: | ||
print(util.bold(util.color_red('Couldn\'t find a C compiler. Tried gcc. Try specifying a compiler with --c_compiler_path.'))) | ||
elif ext == '.cpp' and args.cpp_compiler_path is None: | ||
if sys.platform == 'darwin': | ||
print(util.bold(util.color_red('Couldn\'t find a C++ compiler. Tried g++-{9,10,11,12}. Try specifying a compiler with --cpp_compiler_path.'))) | ||
exit(1) | ||
else: | ||
print(util.bold(util.color_red('Couldn\'t find a C++ compiler. Tried g++. Try specifying a compiler with --cpp_compiler_path.'))) | ||
exit(1) | ||
elif ext == '.py' and args.python_interpreter_path is None: | ||
print(util.bold(util.color_red('Couldn\'t find a Python interpreter. Tried python3. Try specifying an interpreter with --python_interpreter_path.'))) | ||
exit(1) | ||
elif ext == '.java' and args.java_compiler_path is None: | ||
print(util.bold(util.color_red('Couldn\'t find a Java compiler. Tried javac. Try specifying a compiler with --java_compiler_path.'))) | ||
exit(1) |
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.
Big wall of similar text. Maybe we can simplify it?
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.
Is it better now? 273e79e
arguments = [] | ||
if ext == '.cpp': | ||
arguments = [compilers['cpp_compiler_path'] or compiler.get_cpp_compiler_path(), program, '-o', output] + \ | ||
'-O3 -lm -Werror -Wall -Wextra -Wshadow -Wconversion -Wno-unused-result -Wfloat-equal'.split(' ') |
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.
can we make this as a variable/argument and then just pass C_FLAGS
?
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.
Maybe we should add flags to config.yml and if none are set then the code should use less strict flags then those that are now used?
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.
Or by default the flags should be the same as those that oioioi uses
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.
It would indeed be beneficial to be able to pass custom flags, e.g. -fsanitize=address,undefined
or -D_GLIBCXX_DEBUG
, or temporarily disable one of the warning flags.
But then, the calculated times won't necessarily be the same as the ones on sio2 and it might also trigger the sinol_expected_scores
mechanism. If we want to have the ability to specify flags, it should give a warning that the times might not be the same and ignore the sinol_expected_scores
. Probably later we would want to have a sinol-make verify
that runs each command and checks whether they work as expected (e.g. the input files haven't changed their hashes, they satisfy the inwer
, the output files are correct, the sinol_expected_scores
is set as expected, etc) and in this command we wouldn't want the user to specify the custom flags.
To do it perfectly we might need to put into it more thought and the implementation won't be trivial. I think, at this point, it's better to create an Issue for later, focus on merging this PR and adding non-necessary functionality after writing basic tests.
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 created the issue #4, so I think that we can merge this PR
* Add flag to choose template This change allows providing a custom template arg flag -t/--template: ``` sinol-make init foo -t [repo link or disk path] [optional subdir] ``` It defaults to the upstream repository and example_package subdir. Changed the example_package id pattern from `abc` to `__ID__`. All filenames and file contents are now substituted. Changed the positional output directory argument to `-o/--output` flag to help avoid accidents. Added result directory cleanup on failure. * Test quick fix #1 * Always cleanup tmpdir * Add other git url schemes * One more used_tmpdir tweak * Pacify tests #2 * Leave old 'abc' template string for now * Test without connecting to github Try accessing the local git repo in the project root first when cloning example_package. Only if that doesn't work, fall back to online github. Also adds some extra local path tests to init/test_unit. Also removes one unnecessary os.getcwd() call. Also removes the old "abc" template string hack since we test the current template now. * Fall back on copying local directory instead of online github
What's left to do:
check if dependencies are installed for run command (time and timeout)add measuring time and memory with python as an option (do we want this?)