[go: up one dir, main page]

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

extend the intermediate folder with libname_prefix+lib_modifier #67

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

thomas65g
Copy link

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
...

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
...
@jwillemsen
Copy link
Member

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
@thomas65g
Copy link
Author

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.
<%lib_modifier%> is the key of my request

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.
The underscore I put in is just for faster reading – a cosmetic feature

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 =
@jwillemsen
Copy link
Member

output_subdir is documented as below, I think your changes do change this, or not?
output_subdir = This is used in determining the sub-directory under which intermediate files will be placed.

@thomas65g
Copy link
Author

Maybe a change to more general:
output_subdir = This is used in determining the sub-directory under which files will be placed.

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
The original folder structure below
├───vc9
├───vc9_int
│ ├───VC9_calc_d
│ │ ├───AMD64
│ │ ├───I386
│ │ └───toradex_ce700
│ └───VC9_main_d
│ ├───AMD64
│ ├───I386
│ └───toradex_ce700
└───vc9_lib

@mitza-oci
Copy link
Member
mitza-oci commented Aug 6, 2018

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 *.mpt files right, output_dir is always set to something (unless the user customizes it). I would not be in favor of the defaults output locations of the final binaries (*.dll, *.exe, *.lib) being modified. The default behavior should match what VS itself does when create a simple project using the UI. Other layouts are fine to support as well, but shouldn't be the default.

@thomas65g
Copy link
Author

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.

@jwillemsen
Copy link
Member

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

@jwillemsen jwillemsen removed their request for review December 11, 2019 12:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants