February 12, 2018 at 17:30 #20048
I have the following solution structure (not exact but the idea):
This structure — the source file Hello.cpp is outside the project directory — does not work for me for Linux builds. Windows builds work fine. Linux builds work only if I move Hello.cpp into the project folder. The build error message is like this
1>make: *** No rule to make target ‘../../../Hello/Hello.cpp’, needed by ‘VisualGDB/Debug/Hello.o’. Stop.
1>VisualGDB/Debug/Hello.msbuild-mak:13: recipe for target ‘all’ failed
The internal VS2017 15.6 preview 3 Linux build works better (though VS2017 RTM does not work at all) but I am not happy with it (it still has problems with more complex sources structure like
So the question is do you plan to support complex src directory structures outside the project directory? The reason I need it is the cross-platform development when the code is generally the same with some rather small specific variations like specific.cpp for Windows and Linux builds above.
Thank you.February 12, 2018 at 17:33 #20049
It looks like the formatting with spaces is gone. It should be
-src2.cppFebruary 12, 2018 at 19:43 #20052
Please, note I have solved the problem with the “File synchronization” setting (I do not use Project directory and manually set the copy rules with absolute paths). But I believe I still need a better solution with macro variables because setting absolute paths in the project files is the short-dated solution only.
February 13, 2018 at 00:11 #20069
- This reply was modified 1 week, 4 days ago by support. Reason: formatting
The easiest way to work around this is to create a separate pseudo-project (e.g. using the Custom project wizard), that will copy the root directory to the Linux machine, and reference it from the other projects. Let us know if you need more details on setting this up.February 13, 2018 at 00:39 #20071
Thank you for your help. I will consider this way a little bit later. At this very moment I have the following situation: my rather complex VS solution consists of many projects. Their sources and project files reside in different directories and have common and private includes. So I have to point out the entire solution root and the compilation of the very first project copies everything. This is a kind of strange but is not necessary bad. I am just happy with the fact that you are capable to handle the very structured source code tree of the solution (the internal VS 2017 Linux support copies files flat and they lose their private “../asdf/jj.h” headers structure and fail to compile).
For now I miss the ability to point out the system variables like MY_BIN=… in a bat-file that starts the solution and then have in my projects $(MY_BIN)… for output, intermediate etc. directories. This is very useful for branch-driven development. And I do not have to think about how to copy all dlls to a common place to be able to run and debug a complex solution. I just press F5 and it works. Always. I am totally new to Linux but I am dead sure they shall have somewhat similar (I believe make/install is a kind of a myth and they must have a way to run several gdbs to compare the control flow for different branches). So it would be nice if you allow remote system vars and help such a convenient approach. BTW I have used to place such settings in common project property sheets because the configuring tens of projects is not a funny thing. Just need to check if you support them.February 13, 2018 at 04:47 #20078
OK, no problem, let us know if you decide to try out the pseudo-project approach.
VisualGDB MSBuild projects do support environment variables and property sheets the same way as the regular VS projects do. Let us know if you need any help configuring them.
You must be logged in to reply to this topic.