Path Names in libs and dll

[JohnF]

I've just noticed that the path names of .obj files are in the compiled static libarays and dlls, can these be taken out?

example

B:\Projects\misc\output\line.obj.
B:\Projects\misc\output\str.obj.
B:\Projects\misc\output\sort.obj.
B:\Projects\misc\output\toint.obj

John

[frankie]

Yes, this is one of the reason for which I cut exe's and objs from zipped projects.
It should be an MS requirement for source tracing during debug, but I have seen that MS stores relative paths (for privacy reasons I hope).

[Pelle]

Originally I made polib behave like MS lib, storing any specified path for each member file. After that I havn't given it much thought.

Looking at it now (quickly), this seems rather useless. I think the only time the path matters is when extracting a member from the archive: it helps separating thispath\name.obj from thatpath\name.obj - but this could be handle in some other way.

The IDE will always use fully qualified paths internally, and also pass them to external tools, so this is why they are included in the generated libraries.
It's a little late to do big changes for version 8.0, but I will look at this for a later version.

For now, what you can do is this:
1) Create an empty directory
2) run "polib -explode some.lib" in this directory
3) run "polib *.obj -out:some.lib" in this directory, assuming there are no duplicate (base-)names in the library

Not specifying a path for the "*.obj" part should remove all paths from the library...

[JohnF]

That worked for libs thanks.

Can the same thing be done for exes?

John

[Pelle]

You are not saying in which part of the executable you see such paths, but I can only think of them being part of debug info.
Turning off the generation of debug info (for the linker) should do the trick...

[JohnF]

You are right - thanks.

John

[frankie]

Unless you are using assert() and NDEBUG is not defined....