I cannot compile VisualGDB project

Sysprogs forums Forums VisualGDB I cannot compile VisualGDB project

This topic contains 5 replies, has 2 voices, and was last updated by  support 3 months, 1 week ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #20048

    Michael
    Participant

    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.

    #20049

    Michael
    Participant

    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

    #20052

    Michael
    Participant

    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 3 months, 1 week ago by  support. Reason: formatting
    #20069

    support
    Keymaster

    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.

    #20071

    Michael
    Participant

    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.

    #20078

    support
    Keymaster

    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.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.