Skip to content
This repository has been archived by the owner on May 12, 2018. It is now read-only.

compiler respects 'keep_going' flag #354

Merged
merged 2 commits into from
Apr 2, 2015
Merged

compiler respects 'keep_going' flag #354

merged 2 commits into from
Apr 2, 2015

Conversation

vladdu
Copy link
Contributor

@vladdu vladdu commented Sep 2, 2014

I am creating this PR as a base for further discussion.

I found that this change works fine for me, but I don't know if the fact that the worker pid is not removed has any bad effects.

@ghost
Copy link

ghost commented Sep 2, 2014

In addition, the commit message should be rewritten, so compiler respects 'keep_going' flag should be base_compiler: respect 'keep_going' flag, but a much more useful commit message would be:

Respect -k on a per-file level during compile

To more closely mimic `make -k`, change base_compiler to print an
error and continue building when -k is enabled and a file does
not compile.

Also, we should add tests (extend inttest/erlc or add a new one).

This is a companion patch to go with #322.

@vladdu
Copy link
Contributor Author

vladdu commented Sep 2, 2014

Yes, there will be tests and better messages. I wanted just to get a second opinion first.

@vladdu
Copy link
Contributor Author

vladdu commented Sep 3, 2014

Note to self: there are more commands that don't respect 'keep-going', for example xref.

@ghost
Copy link

ghost commented Nov 28, 2014

#322 just got merged and we settled on not turning errors into warnings. It would be great to include this in rebar 2.6, so how soon do you think you can finish the branch?

@vladdu
Copy link
Contributor Author

vladdu commented Nov 28, 2014

I will get to it in the next few days.

The only question mark is how to keep track of the worker pid... I'm not sure how to find out which one failed.

Is it ok to move "maybe_report(Error)"? Then the compiled/failed message serves as a marker for when a file has been processed.

@ghost
Copy link

ghost commented Nov 28, 2014

I will get to it in the next few days.

Thanks, sounds good.

The only question mark is how to keep track of the worker pid... I'm not sure how to find out which one failed.

Is it ok to move "maybe_report(Error)"? Then the compiled/failed message serves as a marker for when a file has been processed.

It should be possible. Let's see what we can figure out.

@vladdu
Copy link
Contributor Author

vladdu commented Dec 2, 2014

Updated the commits, added tests.

true ->
?WARN("Continuing after build error\n", []),
compile_queue(Config, Pids, Targets)
end;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the indentation wrong here?

@ghost
Copy link

ghost commented Dec 3, 2014

Any reason to add a test in test/ and not inttest/ (maybe extend inttest/erlc)?

@ghost
Copy link

ghost commented Dec 3, 2014

@vladdu, should we try to adjust all commands with this pr?

@vladdu
Copy link
Contributor Author

vladdu commented Dec 3, 2014

I don't remember why I didn't write a inttest test, Probably because eunit is a bit more familiar. Do you think it would be better to change it?

I think I checked all commands, but I may be remembering wrong. Will check again.

@ghost
Copy link

ghost commented Dec 3, 2014

I don't remember why I didn't write a inttest test, Probably because eunit is a bit more familiar. Do you think it would be better to change it?

We already have erlc tests in inttest/, so I think it's better to have the new tests there as well.

@@ -0,0 +1,195 @@
%% -*- erlang-indent-level: 4;indent-tabs-mode: nil -*-
%% ex: ts=4 sw=4 et
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like this entire file is indented with tabs? I think that's against what we usually do, but I can re-edit it when merging if you want.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weird, probably I used a different editor for that one. I will fix that.

@Tuncer suggested that it would be better to reimplement this as a retest suite, so it will get rewritten anyway.

@ferd
Copy link
Contributor

ferd commented Dec 4, 2014

This seems good to me outside of the aesthetic thing.

One remark I have too is that in the last -k support branch we enforced printing errors when detecting something wrong, while here we have warnings. However, the current warnings are added specifically when skipping, so I figure this is okay. Does everyone agree with me on this?

@ghost
Copy link

ghost commented Dec 4, 2014

@ferd the warnings printed in rebar_base_compiler are fine because an error is printed first. Maybe xref should print something descriptive, though.

@ghost
Copy link

ghost commented Apr 2, 2015

ping?

@ferd
Copy link
Contributor

ferd commented Apr 2, 2015

I'd like this to be rebased to merge it. If we don't hear back, then I'll do it myself, but these are busy days and if I can avoid rebasing this myself, I'd like to.

@vladdu
Copy link
Contributor Author

vladdu commented Apr 2, 2015

I'll rebase it.

Is it okay to keep the test as they are, or should they be rewritten as retest tests?

@ghost
Copy link

ghost commented Apr 2, 2015

It'd be nice to have it as a retest test, but it's fine as is once you fix the formatting issues pointed out by @ferd.

@ferd
Copy link
Contributor

ferd commented Apr 2, 2015

I'm guessing the retest suite would provide a better integration, but if the tests run along with everything else and represent actual use cases, I personally do not mind much on this. @Tuncer ?

@ghost
Copy link

ghost commented Apr 2, 2015

See earlier #354 (comment). It'd be nice as retest tests, but it's fine as is.

@vladdu
Copy link
Contributor Author

vladdu commented Apr 2, 2015

I hope the formatting is okay now.

@ferd
Copy link
Contributor

ferd commented Apr 2, 2015

It looks good to me. @Tuncer any last comment before I merge this?

@ghost
Copy link

ghost commented Apr 2, 2015

You can merge it.

ferd added a commit that referenced this pull request Apr 2, 2015
compiler respects 'keep_going' flag
@ferd ferd merged commit c3b09ba into rebar:master Apr 2, 2015
@vladdu vladdu deleted the compiler_keep_going branch April 3, 2015 07:18
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
2 participants