[Michael]

I use VisualGDB-5.4r4-trial.msi with VS 2019 release (not preview) on a fresh test machine (Win10, physical, not VMWare, but through RDP) as far as I cannot evaluate VGDB on my workstation any longer. Though I have had to reinstall it many times (non-standard directory) and alternate it with one of the previous version (I do not have it anymore but I believe it was 5.4r3 — a version with the new files synch feature I have been told about by the people who follow the information about VGDB).

[Michael]

Very honest, thank you. We are evaluating VGDB to see if it is capable to perform our basic everyday tasks right now. At this very moment our situation is as following:
1. We can use our official build system on Linux (it is rather inconvenient for development process) and native Visual Studio 2017 Linux support for debugging only (VS just cannot build our complex projects on Linux now).
2. We can purchase VGDB and support and try to solve its existing problems (at least problems for us).
3. We can continue to use (1) and look for other solutions (like WinGDB and… these are all options as I believe).

Personally I believe in VGDB and your ability to make it the way we need it (to fully mimic Windows facilities). But our hardware guys will need the things to be available just out of the box (they completely lack the curiosity for taking troubles with new stuff). So we will need to estimates all our options.
I thank you for your help and very interesting product.

[Michael]

I thank you for your help. But it looks like I am not qualified enough to make someone else custom build rule to apply to VGDB. I use win_flex_bison-2.5.5.zip (679159 bytes long and it exceeds your maximum attachment size but it is available on the internet by name). The project looks like to be here https://sourceforge.net/projects/winflexbison/ and I am ready to update my winflexbison to the up-to-date version.
It looks like with their VS custom build rules I already have bullets 2 and 3. And I just need to register with VGDB somehow. I also suspect their way to run win_flex.exe (I use flex only) confuses the VGDB plug-in. If you have a possibility to provide me any help with the win_flex custom build rule from win_flex_bison-2.5.5.zip or up-to-date version I would really appreciate it.

[Michael]

> In the meanwhile feel free to try out our Advanced CMake subsystem – it works much better with
> large projects containing multiple executables and libraries as the build is orchestrated from
> the Linux side and CMake running on it knows exactly how to copy/remove the files.
1. It looks like VGDB does not support Advanced CMake subsystem for libraries. I can choose it for the Application (executable file) only.
2. I do not know CMake but it looks like it requires to store it’s build files among the sources. We cannot afford it. We can use different build systems for different purposes as far as they reside in a separate location and do not interfere with sources or official build system (that also resides in a separate location). For example my experimental MS Linux, VGDB, Intel performance tools, etc. projects reside in separate folders and I can just delete them (folders) anytime without any harm to the others.

[Michael]

> Please try following our <span style=”color: #24890d;”>Qt MSBuild tutorial</span> for a detailed example of defining rules for
> running custom tools on Linux

Sorry, but as I have written above “I probably shall mention that I run custom build flex step on the Windows machine and you probably expect win_flex.exe on Linux (just a guess).” I do not run my custom tools on Linux. I have mentioned it specially even the name of the custom tool — win_flex.exe  — undoubtedly says this is the Windows executable. I have read the article you have pointed me out and I still cannot figure out why VGDB project cannot find win_flex.exe. Am I right in my assumption that it looks for it on the Linux machine? This is not my case. I need custom build step on the Windows machine.

BTW my assertion that VGDB uses Windows project build generated flex scanner was totally wrong — the Windows generated scanner cannot be compiled with gcc due to Windows includes like io.h and missing unistd.h (win_fflex does have Windows compatibility option and there is the different for Windows and VGDB project). The reason why I was able to compile VGDB project is that the scanner have been generated with MS native Linux build step. So MS Linux project runs my flex custom build step correctly.

So I believe you do not understand my problem. I need VGDB run custom build step on the Windows machine, my custom tool is on the Windows system path and is visible from anywhere on my Windows machine. More over during the project build phase (solution explorer–>my project–>right click–>Build) VGDB totally ignores custom build step and even if it is incorrect does not emit any error. The custom build step can be started only for solution explorer–>my project–>lex file–>right click–>Compile sequence (and it fails with unfound win_flex.exe error).

Can you please reconsider my problem?

[Michael]

> As a workaround, please try changing the default DPI in Windows Display Properties
This breaks a some other programs I use. I have tried it but ended up with the enlarged fonts.

> or simply use the <span style=”color: #24890d;”>Magnifier</span>
I have tried it and found it extremely inconvenient. I would prefer Ctrl+, Ctrl-, Ctrl* facility for all windows (or even screen itself) like in browsers but it looks like the Windows guys are forbidden to copy somebody else’s solutions.

> We will fully support inheriting the VS font size once we fully switch the properties window to
> WPF in a few releases from now.
Please, be quick. Otherwise the MS will rewrite Windows GUI from XML to JSON and we will be stuck again.

[Michael]

I am still not sure of what you mean. Here is a screenshot of the MS project properties I am able to read and VisualGDB properties I almost cannot read.

Attachments:

You must be logged in to view attached files.

[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.

[Michael]

> Before we can do that, could you please check whether the issue only affects WinForms settings
> pages (e.g. Project Properties), or does it also affect the WPF settings pages (e.g. Advanced GDB Settings)?

Project settings (project right click->Properties) are totally OK. They use enlarged font I have set in Tools –> Options. But project right click->VisualGDB Project Properties are totally unreadable to me. I believe you could use Tools –> Options –> Environment font for your dialog.

[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, 9 months ago by support. Reason: formatting

[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

[Author]

Posts