Line ending confusion in generated files of Xtext project? #2778
Comments
|
this issue is new to me. unfortunately with company change i have no suiteable windows machine anymore to have a look. |
|
The Windows changes that you linked are in the above mentioned remaining 24 changed files after I applied the gitattributes. I can try to have a colleague set up another Xtext installation on his machine next week to verify he sees the same. |
|
maybe a default on oomph or egit side has changed? |
|
Hi @Bananeweizen,
|
|
I've just tried the Oomph setup in Windows as well. I mostly use Linux and sometimes macOS, while I rarely used Windows. I'm experiencing the same problem as well! We are aware of a few Xtend generated files with Windows EOLs, which is #2293 for which I recently proposed a fix #3004 However, I experienced the bigger problem reported here, I seem to understand:
I seem to understand that "autocrlf=true" is the correct setting in Windows, and @HannesWell also recently provided a merged PR normalizing a few files with incorrect line endings. Of course, I can reset hard, but this is very annoying. @Bananeweizen says that
So maybe we should not have that setting in our projects? |
|
A few more experiments (in Windows): the projects where this happens (again, independently from #2293) seem to be where we have Removing the file and rebuilding fixes the problem in that project. @cdietrich I can provide a PR removing all such files, what do you think? |
|
unfortunately i have no idea. |
|
I see those files were added here https://github.com/search?q=repo%3Aeclipse%2Fxtext+Set+UNIX-style+linebreaks&type=commits but I see no reason why they are there. No, @cdietrich , the files you're mentioning, which are correctly regenerated/updated, are |
|
@szarnekow do you remember why its this way |
|
Probably having
The resource preferences are even generated by the eclipse core (probably even the resources plugin itself). This changed a few releases ago. Regarding m2e updating the configuration: Automatic updates can be disabled in the workspace preferences and since the last release even in the project preferences. |
|
@HannesWell I'm talking about "runtime.prefs", not "resources.prefs". |
|
Yes. My second paragraph was just for information in case you didn't knew it already and it is of interest for you. |
I can imagine that it was done to get a stable compilation result on windows and linux machines. This is only possible if files are checked-out |
Meaning if trace-files are different since the offsets would be different on windows and unix |
|
As far as I know, not using By removing the settings of Unix EOLs nothing broke. |
|
Start rant. Here's what my experience says. Tell everyone on Windows that they should use only Linux line endings. Then if the tools are bad and generate only Linux line endings rather than respecting your settings, you won't notice, the tools will just remain broken, and the tools will never be fixed. But that makes everyone happy, especially the people not on windows, so just do it. 😱 End rant. Note though that minimally you should use I can see many bad solutions in the project catalog:
Here is a good one:
|
|
@merks I don't understand what you're suggesting. |
|
I'd leave it as true. I wasn't sure where this thread was going, didn't have the time to read it in detail, but was hoping it would not lead to simply removing the setting because you can see how many other projects have reached that questionable conclusion. Sorry for the noise. |
|
@merks no problem, and thanks for the confirmation :) |
|
I think you've specified the task such that it always kicks in when you start.
Maybe you want it only for new projects added to the workspace? |
|
Mh.. that might be the cause, true! But the problem happens only in Windows, not in Linux, nor macOS... |
|
"The problem" being it always runs? |
|
Yes, exactly: when you restart Eclipse, it will always run; but only on Windows. |
|
I see. That's quite unexpected! I hate when OSes behave differently. It's too much work to track down such problems... |
|
I'll check whether the Unix EOL settings were the culprit, when I'm on a Windows machine |
This should deal with the problem of always getting a clean build in Windows, each time you open the development workspace. See #2778 (comment)
|
@Bananeweizen @pbrossel everything should be fixed now (together with #3004) Oomphing from scratch or updating with Oomph after updating to |
Is this already part of the oomph setup? |
@szarnekow I don't think we can enforce that on a per-OS basis. Can we @merks ? |
|
Oomph's git clone task does this configuration by default for every clone unless you have an explicit configuration for that in the git clone task itself. With some trickery I think it's possible do set it differently only different OSes, but given it's a no-op on Linux and Mac and I believe even there it would prevent checking in Windows line endings, so I don't see a need to configure it differently on different OSes. |
|
@merks so, if I understand correctly, by default Oomph sets autocrlf=true in Windows and does nothing in macOS and Linux, is that correct? If so, we're all fine. |
Thanks a lot to all having worked on this issue ! But there are some questions / remarks :
|
|
@pbrossel Very quick answer about the crucial part (I'll try to answer the other questions ASAP): if you clone a repository manually, core.autocrlf=true must be set appropriately in the user global git configuration (~/.gitconfig), and, IIRC, it must be done before cloning. Concerning the fake changes, are they really fake or do they still contain differences? Note that you must have the latest Xtend in your IDE so that you have the version with these changes #3004. |
I'll retry it according to your advice.
I thought they were 'fake' changes, but it could be the result of using the wrong version of xtend in the ide.
At least these 4 generated sources come back to the original version after installing the IDE updates.
Where can I check if the changes are contained in the updates ? |
|
@pbrossel your version of Xtend is the latest one, which contains #2993, where @HannesWell replaced the use of Guava After you install the new version of the Xtend compiler, as you have already done, you have to trigger regeneration in the projects showing dirty files (since now the full build clean Oomph task is not triggered anymore on existing projects, as you saw above). There's no need to fully clean the whole workspace: only cleaning the single projects with dirty Java files is enough. Please, let me know. |
I first removed the 'fake' changes, and rebased on your latest commit and got no changes at all : ok.
I then cleaned and rebuilt the first project in the list of fake changes
Opening the compare editor by double clicking on the first unstaged change shows
Opening the working tree version using the context menu on the first unstaged change opens the xtend source.
The button
So I guess that there are still some fake changes around. I get 219 changes with the same symptoms after having done a full clean rebuild :
Note that I did not clone again after setting user global git configuration to autocrlf=true I'll try to start from scratch with a fresh clone and see if it solves the problem. |
|
Even if setting the core.autocrlf=true in the user settings before cloning (via Egit), the clone's config does not contain the setting.
I now added the The new clone works better ! 👍 but a full rebuild still shows 2 dirty files :
You can see the details of the changes here |
|
this seems to be the inverse change of which target platform did you select in oomoph? xtext-latest/2024-06? |
If I remember well, I selected 'latest' when installing 2 weeks or so ago : 2024-03 was the
The currently starting IDE still shows
This is the target platform setting :
But
I guess I have to do the setup again, or can I ask oopmh to do it ? |
|
Try Help -> Perform Setup Tasks. That should update everything, including the installation. |
|
Thanks for the hint.
Do I have to switch the active target platform to
And a clean rebuild of project
Note : Changing the active target platform does not seem to be a good idea :
|
|
The version of your eclipse and the version of the target platform are two different things. The version of eclipse is the one you selected when you select the distribution in oomph, the target platform is the one you select as an xtext property. The target platform is used for compiling and running tests. |
|
You guys need an oomph configuration that chooses the latest product version so that things always stay up to date. Open an issue and I will help. But I have no time this week. |
|
@LorenzoBettini Yes, I agree. But I got 2 dirty files when doing a full rebuild i.e. compiling because of having the wrong eclipse version (if I understood @cdietrich right : #2778 (comment)). It's not a problem for the issue I'm currently working on #2337 (comment). Not easy for newcomers like me to guess the steps to do to catch up with the latest changes in the project. |
|
@merks do you mean an issue here in Xtext? @pbrossel I think @cdietrich referred to the target platform, which you can update either with Oomph by selecting the latest one or by opening the Concerning the steps to catch up with the latest changes, I don't think there's a real workflow but to update now and then. ;) Now and then, "dirty" files like the two you mentioned can show up. Since you already have the latest Xtend in Eclipse, it should be enough to update the target platform. I had never seen the warning from PDE. You might try to ignore that. |
|
You can use Navigate -> Open Setup -> Installation and via the properties view can switch to any product version:
Other projects have a configuration:
This allows you to determine/specify exactly which product and which version is to be installed, and can specify variable choices so the user can't make mistakes and the user needs to read fewer instructions. It's quite simple: |
|
i still wonder what jdt change causes the last problem. |
|
@merks I changed the IDE version successfully. Thanks for the advice.
Should I change the
Oomph just allows to select a jre, not a jdk.
The whole discussion was very interesting and I learned a lot. @cdietrich I can confirm that the 2 dirty files have disappeared after a clean rebuild. @LorenzoBettini Did you find some time to look into this ?
|
If you perform setup tasks (not from scratch), it will update your IDE. A small warning: using the "latest" in your IDE (instead of "latest released") might expose you to some bugs introduced in the currently developed Eclipse or one of its plugins (e.g., #3018).
You can manually add a JDK to let Oomph know about that.
well... it's automated... it's the small initial configuration that requires a few steps ;)
Great! :)
sorry, I had missed that. Your solution is a bit... "brutal"... ;) in general, not specific of Xtext, you first fork the github project, and then, during the Oomph setup, you specify the URL of your fork, instead of the main one. Alternatively, if you cloned the main one, you can add your fork as an additional Git remote (either from the command line or from Egit); of course, no need to clone it from scratch, just as a remote. Of course, when you push, you have to push to the remote of your fork. In general, it's good to have also the main repository as a remote in order to easily keep your fork up to date with the main one. |
|
@LorenzoBettini Thanks a lot! All open questions got answered 👍 ! |
When I create a new Oomph setup for the Xtext project on my Windows machine, then Oomph automatically sets autocrlf=true, even though there is no such attribute in the *.setup file:
That in turn leads to all the Xtend generated Java files having CRLF in my local index (while the Github repo uses LF). But during build and re-generation all these files get LF only (which fits to the projects having the Unix line ending setting in their project properties). Therefore the IDE has 800+ changed files after a restart, almost all of them with newline changes only, looking like this:
I do use a personal Oomph setup, but I'm not aware of any setting that would cause Oomph to add the autocrlf just for me, so I suspect this should be broken similarly for everyone on Windows. If that is true, would it be useful to explicitly set autocrlf to another value in the *.setup or alternatively to set
*.java text eol=lfin a.gitattributesfile eventually? I've used the gitattributes approach locally, reset hard, and since then my staging area has only 24 changes files, where most contain actual non whitespaces changes (which would be another thing to investigate later).The text was updated successfully, but these errors were encountered: