www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11035] New: Bad solution dependencies to C++ projects

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11035

           Summary: Bad solution dependencies to C++ projects
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: VisualD
        AssignedTo: nobody puremagic.com
        ReportedBy: r.sagitario gmx.de



PDT ---
original report: http://www.dsource.org/projects/visuald/ticket/164

reported 10/27/12 13:07:46 by TurkeyMan for version 0.3.34
bug in Language Service

So I have created a solution with a C++ lib, and a D executable.
Set the solution dependencies so the D exe depends on the C++ lib, and should
attempt to link it automatically.
It is a 64bit project, using the new DMD, which should use MS link, and
therefore able to link the C++ lib against the D exe.
It does seem to try and link the dependency, but there is a problem:
1>LINK : fatal error LNK1104: cannot open file 'C:\Program Files
(x86)\Microsoft Visual Studio 10.0\dist\lib\x64\Fuji_.lib'
It seems to be giving the wrong path and filename to the linker.
The proper path should be: dist\lib\x64\Fuji_$(Configuration).lib relative to
the dependent project's $(ProjectDir?).
I'm not sure why it prepended the visual studio path, but it should use the
project dir of the dependent library, and also, it didn't resolve the
$(Configuration) macro, so half the filename is missing.

Comment 1: 10/28/12 16:10:23  by sagitario


don't resolve the filenames correctly (closed))), but now I can reproduce the
problem: the enumerator of the VC project outputs yields a standard file name
for the target DLL, but for the import library, it doesn't replace the macros.
I'd say this is a bug of the C++ project plugin (and a regression from VS2008).
How is poor little Visual D supposed to know how expand all the plethora of
macros VC supports?
What happens now is that the macros are expanded in the context of the D
project, so using $(ConfigurationName) instead of $(Configuration) and
specifying the path relative to some common directory like $(SolutionDir)
should work.

Comment 2: 10/28/12 20:33:37  by TurkeyMan

Replying to sagitario (Comment 1 for ticket:164):



don't resolve the filenames correctly (closed))), but now I can reproduce the
problem: the enumerator of the VC project outputs yields a standard file name
for the target DLL, but for the import library, it doesn't replace the macros.
   


Ah yeah, I did report it before. It was never fixed.
In this case, I'm not linking against an import library for a DLL, I'm linking
against a static lib, but I would expect a DLL set as a dependency to link
against the import library as you describe.


    I'd say this is a bug of the C++ project plugin (and a regression from
VS2008). How is poor little Visual D supposed to know how expand all the
plethora of macros VC supports?
   


Why should D need to expand those macros? How does it resolve that filename? Do
you inspect the C++ project properties for those strings manually?


    What happens now is that the macros are expanded in the context of the D
project, so using $(ConfigurationName) instead of $(Configuration) and
specifying the path relative to some common directory like $(SolutionDir)
should work.
   


I can't do those things, since those settings are in the C++ project.
Target Name: Fuji_$(Configuration) -> Fuji_Debug.lib
And the C++ project also has the output directory set where it writes the
output to.
There is nothing wrong with the C++ project, it builds correctly and all macros
expand properly, but when set as a dependency of a D project, the D project
just doesn't know where to get the output, and the name is wrong (macro
expansion is missing).
How does VisualD resolve the dependency? There must be some logic in VisualD
that finds the output path for a dependency that it is set to try and link
against?
This can't be addressed from the C++ side, that's working correctly.

Comment 3: 10/29/12 03:36:25  by sagitario


    In this case, I'm not linking against an import library for a DLL, I'm
linking against a static lib
   


It's getting worse :p If you have set the import library while the project was
configured to be an executable/DLL, the import library is still passed as an
output of the project. To get rid of it, you have to switch back to DLL, clear
the "Import Library" entry and switch back to static lib.


   Why should D need to expand those macros? How does it resolve that filename?
Do you inspect the C++ project properties for those strings manually? 
   


Visual D uses the IVSOutput interface to query the outputs of a project
(http://msdn.microsoft.com/de-de/library/vstudio/microsoft.visualstudio.shell.interop.ivsoutput_members%28v=vs.100%29.aspx
(http://msdn.microsoft.com/de-de/library/vstudio/microsoft.visualstudio.shell.interop.ivsoutput_members%28v=vs.100%29.aspx)),
I'm not aware of another way. For a DLL project the VC package returns two
items, the target and the import library. The target is properly expanded:
"C:\\Users\\rs\\Documents\\Visual Studio
2012\\Projects\\ConsoleApp2\\Debug\\Project1.dll" 
while the second output yields
"c:\\tmp\\$(OutDir)$(TargetName).lib"
where "c:\tmp" happens to be the working directory where I started the VS debug
session.


    I can't do those things, since those settings are in the C++ project
   


If the VC package is buggy some workarounds will be necessary.
$(ConfigurationName) and $(Configuration) both seem to be supported by VC, so
using $(ConfigurationName) will expand to the same string. But I am afraid
there is no workaround for the working directory being prepended to the name.

Comment 4: 10/30/12 19:53:56  by TurkeyMan

Okay, perhaps we have some crossed wires. I'm not talking about DLL's at any
point - although I think they should also work - they're not my concern.
What path do you see when you set a D project to be dependent on a VC lib
project?
In the DLL case that you just illustrated, would it not be reasonable to take
the dll path/name, and just change the extension to .lib? At least as a short
term work-around. That will be correct most of the time.
It's very weird that the API gives you that tmp path, do you think that's a
bug, or somehow intentional?
In my tests $(ConfigurationName?) no longer works. That was the old macro, it
was deprecated and replaced with $(Configuration) (along with some other
changed macros too).
How do you resolve one and not the other? It must be simple enough to support
both?
I wonder if there is a function in the addin API to resolve paths and macros
and stuff for you. It's crazy for strings containing those macros to leave the
API, and not provide a mechanism to resolve them properly...

Comment 5: 10/31/12 02:48:33  by sagitario

For a VC static library project, the target lib is correct. But if you have
specified an import library (an option not visible for the static lib, but only
if you switch the configuration type to DLL) it is still passed as an output.
Could you verify in the build log that there are actually two libraries from
the dependent project on the command line?
I thought $(Configuration) and $(ConfigurationName) were both supported, as
they are shown in the list of available macros (at least in VS2012). But I can
support them both in Visual D, too.

actual file names around. I'll think about a workaround.

Comment 6: 12/03/12 14:17:37  by sagitario

$(ConfigurationName?) now supported by Visual D, but that doesn't yet help the
bad path passed by VC.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 13 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11035




Commits pushed to master at https://github.com/D-Programming-Language/dlang.org

https://github.com/D-Programming-Language/dlang.org/commit/30a0c704107274ce6d73a532283fae19d4c8f796
Fixes Issue 11035 - Document lack of .stringof reliability.

https://github.com/D-Programming-Language/dlang.org/commit/4cc00e0fe397334cc13e6f904b339ac8bf2a7cad


Issue 11035 - Document lack of .stringof reliability.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 16 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11035


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com



08:25:13 PDT ---


 Commits pushed to master at https://github.com/D-Programming-Language/dlang.org
 
 https://github.com/D-Programming-Language/dlang.org/commit/30a0c704107274ce6d73a532283fae19d4c8f796
 Fixes Issue 11035 - Document lack of .stringof reliability.
 
 https://github.com/D-Programming-Language/dlang.org/commit/4cc00e0fe397334cc13e6f904b339ac8bf2a7cad

 
 Issue 11035 - Document lack of .stringof reliability.


Sorry about that, it was meant to be for 11036.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 16 2013