Sysprogs forums › Forums › VisualGDB › How is EXTERNAL_LIBS defined?
- This topic has 4 replies, 2 voices, and was last updated 10 years, 7 months ago by Anonymous.
-
AuthorPosts
-
April 30, 2014 at 05:57 #816AnonymousParticipant
I have a project that I am generating to support VisualGDB and everything seems fine. But when I make my project depend on another project and build for whatever reason VisualGDB is automatically setting the EXTERNAL_LIBS value to be itself. So if Project1 depends on Project2 and the TARGETNAME := project1.so is set for the first project. When I build EXTERNAL_LIBS is getting set to EXTERNAL_LIBS := /$(BINARYDIR)/project1.so for project1… This obviously won’t build and gives and error.
make: *** No rule to make target `/Debug/project1.so’, needed by `Debug/project1.so’.
When I made projects using the templates it seems to work.
One thing to note is that I am using gyp to generate visual studio projects. This puts all the project files and sln files in the same directory. Everything seems to work ok except for this (and some minor issues like inability to share vgdbsettings).
Any ideas on how the EXTERNAL_LIBS value is set and what would cause it to set the value to be the same project?
May 1, 2014 at 20:19 #3150ketParticipantHi,
VisualGDB will try to take the target name from the dependent project’s makefile. Having all the project files in the same directory could trigger some bug in VisualGDB.
Please go to Tools->Options->VisualGDB and enable verbose output. Then rebuild the solution, the build log in the Output window should show the detected dependent projects and their makefiles. Please give us this log along with the full paths of both projects’ makefiles and project files (.vcproj or .vcxproj files).
May 1, 2014 at 21:24 #3151AnonymousParticipantI fixed this by modifying GYP to support exporting projects to their own directories.
I did try the verbose option before your response here and it didnt say a lot other than it discovered the Makefile needed updating and so it did. It kept reading the wrong makefile though. I tried swapping the projects makefile names (instead of the main project being “Makefile” and the dependency project being “Project2-Makefile”, I swapped them). That didn’t work either and VisualGDB continued to read in the wrong value.
Anyhow this can easily be reproduced in 4.1r10 by making two projects in VS. Make one depend on the other and move all their projects/makefiles into one directory.
Btw do you guys have any plans allow support for a global vgdbsettings file (instead of only per project)? And on that same note it would be nice to be able to move those settings and user settings files out of the project directory. This would make it easier to have one set of settings to maintain rather than have to maintain 1 per project.
May 4, 2014 at 18:50 #3152ketParticipantHi,
Thank you for the reproduction steps, we will try to reproduce and fix the issue.
vgdbsettings files essentially are the project files, they contain the necessary information for building and debugging. They are meant to extend the Visual Studio project files. What is your use case to need a global vgdbsettings file?
May 5, 2014 at 18:09 #3153AnonymousParticipantThe global settings in my opinion would be nice for things like the ssh settings since those would unlikely change from one project to the next in the same solution.
More importantly in my case since the projects are generated I want to be able to keep the visualgdb settings file somewhere else that isnt in the project. This allows me to make changes to it via the Visual Studio plugin and still keep it up to date. Atm I have to create the default settings file and copy it yo the project directory. Since our project files can be deleted and recreated at any time this means making changes to the settings/makefiles we need to make sure to copy them back to our original templates.
Other than this I have managed to get everything working quite well I think. We will be purchasing several copies shortly (if we haven’t already). I do appreciate the quick responses as well.
-
AuthorPosts
- You must be logged in to reply to this topic.