rename .pdb file name as targetname.

[leeonix]

issue: #151

[starkos]

As I mentioned on #151, we'd ideally like to keep the default VS behavior if we can. It would be good to know how and when VS decides to rename that file on its own; we might be able to apply the same behavior.

But as far as this request, it should probably be $(OutDir)%(Filename).pdb, though I think there is a symbol that does all of that. $(OutputFile)?

Also, the tests need to pass.

[leeonix]

yeah, your opinion is quite well. I modify from basename to VS macro name $(TargetName)

[starkos]

Great, that looks better. I'd like to take a quick look at how VS does things by default before I merge this. I will try to do it this weekend if I can!

[akaStiX]

I remember I had issues with Edit and Continue feature, if my pdb's were named after the project's name.
http://industriousone.com/topic/accept-my-bugfixes-please

[starkos]

had issues with Edit and Continue feature, if my pdb's were named after the project's name

Hmm, that's a good reason for more testing. Though not everyone wants their PDB in $(IntDir).

@leeonix: Maybe we should instead add a new API like pdbname() and pdbdir() so that we can leave the default behavior as is, but allow scripts to override it?

[TurkeyMan]

Just a quick thought; I have vague recollection of some of the VS macros changing names between an older version (2008/2010-ish?) and the recent versions. I recall having some projects that were broken because the macro's didn't resolve... is there anyone who can confirm with confidence that this isn't one of the ones that changed name? Perhaps I'm imagining this?

[starkos]

have vague recollection of some of the VS macros changing names between an older version (2008/2010-ish?) and the recent versions…is there anyone who can confirm with confidence that this isn't one of the ones that changed name?

Currently, we don't output a at all and just let VS use its own defaults. So there is no variable being used that could have changed and broken. Unless I misunderstood your question?

[leeonix]

@starkos sorry i'm late. move house recently, very tired.
Someone like me need .pdb file, the minimum requirement is .pdb name. directory isn't real needed. Becaure it's name write in PE file when linked over. I think if we need new API, pdbname() is enough.

@akaStiX what do you think?

[tvandijck]

It used to be this:

    function m.programDataBaseFileName(cfg)
        if cfg.debugformat ~= "c7" and cfg.flags.Symbols then
            local filename = cfg.buildtarget.basename
            p.w('<ProgramDataBaseFileName>$(OutDir)%s.pdb</ProgramDataBaseFileName>', filename)
        end
    end

we changes it back to that... not sure why it was removed, but that is pretty much the behavior Leeonix is looking for I think.... and I reaallly don't want a pdbname API.....

[leeonix]

@tvandijck First modification, I use cfg.buildtarget.basename too.
what do you think using $(TargetName)?

[tvandijck]

Yeah, that should be possible indeed... probably even more generic...

anyway, I don't mind this as a local change here, it's an easy merge... and alternatively we can just override it in our module... that's kind of what the comment in that function suggest we should do anyway.

[TurkeyMan]

@starkos This patch introduces use of $(OutDir)$(TargetName), which I'm not sure if either are among the VS macros that changed names some number of VS versions back.
I think it's fine, I couldn't google that either of those changed names.

[akaStiX]

It used to be this:

    function m.programDataBaseFileName(cfg)
        if cfg.debugformat ~= "c7" and cfg.flags.Symbols then
            local filename = cfg.buildtarget.basename
            p.w('<ProgramDataBaseFileName>$(OutDir)%s.pdb</ProgramDataBaseFileName>', filename)
        end
    end

we changes it back to that... not sure why it was removed

@tvandijck, I guess, it was my request, since this broke Edit & Continue in VS.
Check this comment #162 (comment)

[starkos]

@akaStiX: any chance you could cut-and-paste the code above back into that function and see if you can reproduce your issue? I tried quickly here and couldn't, but I may not have matched your setup.

Otherwise I'm fine with putting the code back in. Like I said above, I removed the markup only to match the default behavior of VS; if it is causing issues for people it should go back in (perhaps bit a comment to remind me why we need it so I don't take it out again in the future :p )

[akaStiX]

@starkos I am running VS2015 ATM and I cannot reproduce the issue I had there. But it was affecting VS2012 back in the days, when I've faced it.

[starkos]

@leeonix: can you update the request to match the code provided by @tvandijck?

if cfg.debugformat ~= "c7" and cfg.flags.Symbols then

I will put together a VS 2012 test and see if I can reproduce the problem and, if not (it may have been fixed by a service pack) we'll merge this and see if anyone yells. Sound good?

[leeonix]

@starkos Yeah, I'll do it.

[tritao]

I'm all for merging this, the old behaviour of naming the PDB the same as the output target makes more sense than the VS default IMHO.

[starkos]

Thanks!

[starkos]

Reposting here so more people will see it:

I've been asked to revisit this and to figure out why this change was necessary.

I manually generated a bunch of projects through the UI, for various versions of Visual Studio. The default Program Database File Name is, indeed, $(IntDir)vc$(PlatformToolsetVersion).pdb. However, on every build I tried this file is also copied to $(TargetDir)/$(TargetName).pdb, and this happens automatically, without the addition of a <ProgramDataBaseFileName> element.

Since it appears in my testing that we get the desired behavior without the need for this element, I'm inclined to roll back #162 and allow Visual Studio to use its default behavior again. Can you provide any more information on why you felt you needed to change it? Is minidump not able to use the PDB file that is already in the target directory?