-
Notifications
You must be signed in to change notification settings - Fork 63
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
Drop the rebuild feature of lfc #530
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.
This looks good to me. This change cleans up Main.java
considerably.
This isn't so much of a clean up as it is a feature removal, and it happens to concern a feature that I use very frequently. One of the motivations behind this code was to simplify the I'm OK with these changes, but I would like to keep the |
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 agree that the Java-based rebuild functionality was:
- too complicated;
- too brittle; and
- not suitable for non-development use.
I've instead worked rebuild functionality into the Bash script, which is tiny compared to the amount of Java code that was slashed. This, however, reminded me of another issue, which is that we do some work on the scripts as part of the release script, which probably has to be looked at (I expect this might break the release). Ideally, we just work some conditionals into our scripts so that no adaptations are necessary for releases.
Currently, the benchmark tests fail because the bash script detects Honestly, I think that lfc should really just be a launcher. It shouldn't be able to build or rebuild the jars. This dual use of the lfc script for launching and building is the main reason why we have to do the brittle patching in our nightly builds. If it would just be a launcher, there would also be no need for patching. I understand that |
@cmnrd: You might be right. I like your suggestion adding the capability to also run stuff using |
I worked on the lfc script, and I think I was able to make it much more robust. With the new design, the script checks first if it is in a developer setup (i.e. are the sources available) or in a pre-built package. Depending on this, it looks up the appropriate jar. The version of the jar is not fixed anymore. In case the script finds multiple options, it uses the latest version. If we are in a developer setup and there is no jar (or a rebuild is requested with These changes also remove the patching from our packaging script. Thus, this closes #434. With these changes, I also convinced myself that it is possible to have an lfc script that supports the rebuild flag and that works in a developer and a packaged context without modification. I am unsure what to do now. We can go for the rebuild feature in lfc, but then the build-lfc script is redundant and I would delete it. Or we use lfc purely for running the standalone compiler and extend the build-lfc script such that it can optionally also run lfc. What do you think? Note that the Windows lfc.ps1 script is not updated yet. |
I have a question: Why can't |
Codecov Report
@@ Coverage Diff @@
## master #530 +/- ##
=========================================
Coverage ? 66.36%
Complexity ? 3462
=========================================
Files ? 132
Lines ? 22294
Branches ? 2883
=========================================
Hits ? 14795
Misses ? 6352
Partials ? 1147 Continue to review full report at Codecov.
|
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've followed your suggestion, @cmnrd, and moved the -r
flag to build-lfc
.
lib/scripts/build.sh
Outdated
fi | ||
|
||
# Check if jar is missing or out-of-date compared to the sources | ||
if [ ! -f "${lfc_jar_snapshot_path}" ] || ! "${FIND}" "${lfbase}/src" -path "${lfbase}/test" -prune -o -type f -newer "${lfc_jar_snapshot_path}" -exec false {} +; then |
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.
@cmnrd: I'm a little unsure about the "${lfbase}/test"
in here. Why should we rebuild if a test has changed?
This came from the original lfc-build
script...
I just realized the the |
The automatic rebuild feature of lfc (
lfc -r
) is convenient for development, but can easily cause trouble (see #521 and #524). I argue that we should drop this feature and let gradle handle the rebuilding for us (see #528). There is already arunLfc
task which provides the same functionality aslfc -r
. This PR completely removes the rebuild feature of lfc and slightly improves usability of therunLfc
task, by setting the default working directory to the root of the LF project (instead oforg.lflang.lfc
as before).