-
Notifications
You must be signed in to change notification settings - Fork 61
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
extend the intermediate folder with libname_prefix+lib_modifier #67
base: master
Are you sure you want to change the base?
Conversation
old: object for debug and release are mixed, because they have the same name [project_top]\output\vc9_int\VC9_agg\x86 -agg_arc.obj -agg_arrowhead.obj new: strictly separated [project_top]\output\vc9_int\VC9_agg_s\x86 -agg_arc.obj -agg_arrowhead.obj ... [project_top]\output\vc9_int\VC9_agg_sd\x86 -agg_arc.obj -agg_arrowhead.obj ...
When there is no libname_prefix and no use_lib_modifier it looks there is an underscore added to the end, shouldn't that only be added when there is libname_prefix used and add another underscore to the lib_modifier part so that when we have a prefix of foo and a lib_modifier of s we get _foo_s, with only a lib_modifier of foo we get _foo |
add underscore in case of use_lib_modifier as cosmetic feature
The scope for my request is just to separate the different intermediate files. <%libname_prefix%> was never used on our side in this context – don't know the reason and I just removed it. Without lib_modifier we get foo_ and maybe that looks strange. Also if I move the underscore into the scope of use_lib_modifier it looks strange for intermediate files generated for shared libs in release mode. shall I do second pull request? |
…AdditionalLibraryDirectories, ImportLibrary it provides folder structure as below ├───vc9 │ ├───AMD64 │ └───I386 ├───vc9_int │ ├───VC9_calc_ │ │ ├───AMD64 │ │ └───I386 │ ├───VC9_calc_d │ │ ├───AMD64 │ │ └───I386 │ ├───VC9_main_ │ │ ├───AMD64 │ │ └───I386 │ └───VC9_main_d │ ├───AMD64 │ └───I386 └───vc9_lib ├───AMD64 └───I386 additional parameters are: -name_modifier VC9_* output_dir = $(PROJ_TOP)\..\output\vc9 libname_prefix =
output_subdir is documented as below, I think your changes do change this, or not? |
Maybe a change to more general: In original behavior, executable file and lib files were overwritten by files of other platforms. By reusing the parameter output_subdir I can avoid the behavior |
If this PR seeks to change the way output_subdir is used, it should also change the uses in vc7 and vc10 (unless they are already behaving that way). If I'm reading the |
vc10 should be changed to the same way, it's not done; it makes sense. vc7 has no platform support, has it? I can follow the arguments to have output_dir the exact same way as VS proposed, but how can we avoid that different compilers overwrite target files? Should vc8platforms.mpt provide an additional template like target_subdir? target_subdir = This is used in determining the sub-directory under which target files will be placed. |
I am concerned that adding the lib_modifier to the output_dir will break user scripts that expect the output in that directory without lib_modifier |
old: object for debug and release are mixed, because they have the same name
[project_top]\output\vc9_int\VC9_agg\x86
-agg_arc.obj
-agg_arrowhead.obj
new: strictly separated
[project_top]\output\vc9_int\VC9_agg_s\x86
-agg_arc.obj
-agg_arrowhead.obj
...
[project_top]\output\vc9_int\VC9_agg_sd\x86
-agg_arc.obj
-agg_arrowhead.obj
...