Reputation: 1917
By exemple, I can define CORE_DIR = "<please change it with your relative path to the core component>
" in the pro
file. Then, the user John could change it in its own customized file (environment) to CORE_DIR = "../../../../john's fancy core"
. (This customized file would be small and clear enough to not be added to the version control system). So, how can I adapt a project to the user's environment (to have the said behaviour)?
This way I can avoid forcing CORE_DIR
value (and so the local paths) for everybody.
Upvotes: 1
Views: 81
Reputation: 9668
I have implemented this in a nice way like this:
# PUT YOUR LOCAL OVERRIDES IN THIS FILE AND DON'T INCLUDE IT IN GIT!
!include( local_overrides.pri ) {
LOCAL_OVERRIDES=false
}else{
LOCAL_OVERRIDES=true
}
Later I can check if local_overrides.pri
was indeed present and included by inspecting LOCAL_OVERRIDES
like so:
message("LOCAL_OVERRIDES ENABLED: " $${LOCAL_OVERRIDES})
Works like a charm. You could also go further and actually create the file with sane defaults if it was missing. I haven't ventured there yet.
EDIT: I decided to put an example for how you could create the file if it does not exist:
!exists( local_overrides.pri ) {
# Please note the single > to truncate existing file if present (should not be necessary but you never know)
system("echo 'MY_VAR1=sane_default' > local_overrides.pri")
# Please note the double >> to append instead of truncate
system("echo 'MY_VAR2=other_sane_default' >> local_overrides.pri")
}
!include( local_overrides.pri ) {
error(ERROR: Could not load local_overrides.pri. Aborting build)
}
NOTE: This is an untested example
Upvotes: 2