-
Notifications
You must be signed in to change notification settings - Fork 82
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
change compile dir #202
Comments
Hm, I think this sounds like a bit of a hairy prospect. Hacking timestamps and keeping multiple copies of the same module on the path sounds error prone. Is there any way you could make the warnings stand out more? |
I thought of forbidding buffer save if there are errors, but then i realized that's just a workaround. Edts compiles in order to "lint" ie. get errors. The key issue would still remain.
|
…#202 This allows the project's main build system to rebuild the BEAM per the project's settings. Otherwise, since the BEAM's modification time is newer than the source's, the main build system will think it has already built it and will skip, possibly hiding warnings.
Hej Thomas :)
Long story short is that I have a dev environment which treats warnings e.g. "unused variable" as errors, but I noticed I get red-handed when using edts, because edts compiles the module, outputs it into the conventional ebin folder, shows the errors, but I miss them, code runs fine, I go into my shell to run "make" (which usually spits out the errors/warnings), but this time make just skips compiling the module altogether (edts just compile the beam afterall, so the timestamp is newer), thus skipping the errors/warnings as well.
I looked through the edts code and it seems that it is by design https://github.com/tjarvstrand/edts/blob/3af8770317a99497c69499692e151ce1ec20806b/lib/edts/src/edts_code.erl#L519
unlike flycheck for instance which compiles the beam inside a temp directory https://github.com/flycheck/flycheck/blob/master/flycheck.el#L6059
Unless the output directory can be changed, how about compiling but keeping to the old beam's modified timestamp? Or slightly less confusing - setting the beam's modified timestamp to 1 second earlier than the module?
Thanks!
Relates to #196, #44
The text was updated successfully, but these errors were encountered: