I cannot compile VisualGDB project

[Michael]

Hello,
I have the following solution structure (not exact but the idea):

Home
Hello
Hello.cpp
Projects
Linux
Hello
Hello.vcxproj
Windows
Hello
Hello.vcxproj

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[1]: *** 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

Device
Linux
specific.cpp
Windows
specific.cpp
src1.cpp
src2.cpp

)

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.

[Michael]

It looks like the formatting with spaces is gone. It should be

Home
-Hello
–Hello.cpp
Projects
-Linux
–Hello
—Hello.vcxproj
-Windows
–Hello
—Hello.vcxproj

and

Device
-Linux
–specific.cpp
-Windows
–specific.cpp
-src1.cpp
-src2.cpp

[Michael]

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.

• This reply was modified 6 years, 2 months ago by support. Reason: formatting

[support]

Hi,

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.

[Michael]

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.

[support]

Hi,

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.

[tomas.khandl]

Same problem here when I’, building project under linux over network. It works as expected when I building project locally with cross-compiler. Have you plan to “fix” this issue with more native solution?

[support]

Hi,

If you are using a custom edition, you can simply add an extra pre-build action to transfer any amount of arbitrary source directories. If you are using a lower edition, simply creating a pseudo-project to facilitate the transfer should work as well.

Another option would be to try the Advanced CMake Project Subsystem and switch your project to CMake. CMake projects can have multiple targets (executables/libraries) inside one project sharing the same file transfer settings.

[Author]

Posts