Skip to content
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

Fix load order for custom project builders and parse transforms #1963

Merged
merged 4 commits into from
Dec 1, 2018

Conversation

ferd
Copy link
Collaborator

@ferd ferd commented Nov 28, 2018

Due to building dependencies with potential artifacts such as parse
transforms or macros, project builder plugins should be included in the
path, but after deps are loaded.

Doing otherwise means that if any of the dependencies is required at
compile time, those of a plugin might get used first.

Fixes #1962 // awaiting confirmation by @hommeabeil

Due to building dependencies with potential artifacts such as parse
transforms or macros, project builder plugins should be included in the
path, but _after_ deps are loaded.

Doing otherwise means that if any of the dependencies is required at
compile time, those of a plugin might get used first.
@ferd
Copy link
Collaborator Author

ferd commented Nov 28, 2018

Tristan pointed out that this should only impact paths when using custom builders so this likely does not fix #1962 yet. I'll need to investigate further

@ferd ferd changed the title Fix load order for custom project builders (WIP) Fix load order for custom project builders Nov 28, 2018
Compile time with parse transforms needs to have the deps first in scope
before the plugins
@ferd ferd changed the title (WIP) Fix load order for custom project builders Fix load order for custom project builders and parse transforms Nov 29, 2018
The app data, when set by `rebar3_app_discover` basically does not
include the modules if it was derived from the .app.src file, even if at
a later point the modules were compiled.

Since there is currently no clear way to add that information reliably
across all compiler versions in all types of compilers, we simply clear
the cache and re-derive the information when required.

This might have a small performance cost, but is required for
correctness whenever an application's first build is run. Specifically,
this bug was detected when a plugin included lager's parse transform,
and the application itself also required it, but two distinct versions
were needed.

This patch finalizes fixing this issue.
@ferd
Copy link
Collaborator Author

ferd commented Nov 30, 2018

Alright this seems to work in all scenarios. Turns out the app details cache was not always blown after compiling, and since we don't know where exactly in the workflow rebar_paths is called, I just decided to always ignore the app detail cache for the lookups. This seems to fix everything up.

@ferd ferd requested a review from tsloughter December 1, 2018 17:14
src/rebar_paths.erl Outdated Show resolved Hide resolved
@ferd ferd merged commit 62ffde8 into erlang:master Dec 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants