May 26, 2013 at 18:43 #575
OK sorry the title is vague but the problem is a bit complicated to explain. Here is my situation:
As mentioned before, I have a very big source code tree. This severely slows down the compile process because just scanning for changes in the source tree is slow. Because of this I wrote my own utility that can scan for changes and copy a changed file to the build machine in less than 1 second. It’s not magic, it simply scans a subset of the tree (only the area I’ll ever make changes to) and also stores file times in a local database, which means if you start out with an already synced source < -> destination, it doesn’t even need to make a remote call to determine if anything changed or not. Hence the sub-1 second speed.
But now let’s say my scan utility determines that no files have changed. In this case I don’t want to initiate a remote build, because even if nothing changed, that also takes a long time since make scans the source tree on the build machine, looking for changes. So what I want to do is control whether starting a build will actually call make on the build machine or not. So the “build actions” under the Build section should be performed conditionally. I can see a few ways to do this, some more viable than others:
1. Figure out how to run a remote command on the Linux build machine from the utility (C#), bypassing VisualGDB. I don’t know how difficult that would be to do.
2. Somehow use the “Set a build variable from the output of a command” to control whether the make command will run or not. Maybe I can pass in the output of my utility as a way to control a remote script to either run make or not. I’m not sure if this is possible. Something like “./myScript.sh $(MyScannerOutput)” or similar.
3. If VisualGDB has a command line mode, maybe I can call it to run remote commands on demand. I doubt this would be possible but who knows…?
4. When pressing F5, manually decide whether a build is required or not. This works but I’d like to automate this.
5. Create multiple project configurations that contain different build steps, some including a make command, some not. It complicate things because now I need to maintain multiple project which can get out of sync, and I need to switch between configurations constantly.
So any advice would be appreciated.
Here is a somewhat unrelated question… Is it possible to create custom variables for all remote machine username, addresses, etc? Right now it seems if another developer gets a copy of the project, they will need to manually go and change all these settings in multiple places all over the project. Ideally I’d like to configure this so someone else just needs to go and change these settings once in one place. Please let me know if this is possible.
Thanks in advance for any help.May 26, 2013 at 23:51 #2432
OK I figured a way out. In my scan utility I create a bash script at runtime that gets copied to the build server. VisualGDB then executes this bash script. I can now put whatever I want in there. If no files changed, the bash script is simply empty.
This also gives me great flexibility to run additional commands from the build machine via this bash script that would otherwise have been tricky to configure via VisualGDB. So now VisualGDB simply runs two commands… A local command that runs my scan utility, and then the bash script that was created by this utility and which it already copied to the build machine.May 27, 2013 at 03:16 #2433
A bit of clarification regarding the file transfer. VisualGDB actually maintains a local source cache as well. After transferring the source files it remembers the file names and their modification times in
VisualGDBCache –and uses it during subsequent builds to determine which files have changed. VisualGDB uses the .Net BinaryFormatter to maintain the cache file, so normally it takes less than a seconds to update the cache. Note that VisualGDB does this for all files in the directory specified in the project settings. You could reduce the time greatly by specifying your working subdirectory instead of the root project directory. Alternatively you could setup shared folders (see this tutorial: http://visualgdb.com/tutorials/linux/ImageMagick/) to avoid file transfers completely. SourceCache.dat
Having an option to skip build command if no source files have been changed is a good suggestion, we will add this to the upcoming release.
Regarding the custom variables, you can currently use the environment variables to do per-user tweaking and refer to those as $(VariableName) in your VisualGDB settings. We have also added a much better support for configurable per-user variables in the upcoming release based on the feedback from other customers (supporting host names, user names, etc), however this will be a major release redefining the usability of GCC settings editing, so it will take 1-2 months before it is out. We could also provide you with a pre-release build once it reaches the point when it passes our standard test scenarios 🙂
P.S. If you are dealing with huge projects with custom types and have C# knowledge, you may be interested in our type visualizer SDK that can be used to let VisualGDB display arbitrary user-defined types in a readable way. You can find out more about it in this tutorial: http://visualgdb.com/SDK/tutorials/SimpleArrayVisualizer/May 27, 2013 at 15:00 #2434
Thanks for the detailed reply, much appreciated.
So let me try to explain the problem I have in more detail… As mentioned before, my source code tree is very large, consisting of many different products that can each be compiled out of this tree depending on which parameters are passed into make. My product’s dependencies are spread out all over this tree, and manually trying to come up with a subset of dependencies is an almost impossible task. So what we all do is just get the whole source code tree and let make sort it out. Note that the same source code tree can be built on Windows and Linux. Windows builds happen locally on my dev system.
Next, I’m in a remote office from where the Linux build machine is. Our network is not super slow, but not super fast either. We are discouraged from using shared folders with these large source trees for the purpose of syncing or building across the network since it would use large amounts of bandwidth.
As for syncing the sources, there are different scenarios. Every now and then, we get the “latest” sources from source code control, and hence the whole tree needs to be synced to the build machine. But for a typical code edit/build/debug cycle, it is possible to isolate just a small subset of the whole tree, because we know exactly which subfolders our own code is in. It is this subset of folders that my sync utility focusses on, which is why it can be fast.
What I’m finding is that VisualGDB is very slow to determine which files have changed (if any), simply because of the tree size. I can probably manually set up the same subset of folders in VisualGDB that I did in my scan utility but it would end up being something like 30 different entries so it will be difficult to set up and maintain. With my scan utility it stores the list of subfolders in a config file that is easier to maintain than VisualGDB when there are many entries.
So the problem is a bit complicated. I’m currently trying to come up with additional ways to handle these different syncing scenarios.
Here are some features of that would make VisualGDB even better:
1. The ability to enable/disable individual actions in the list of actions. This would be especially helpful while setting up complicated actions that need some experimentation.
2. Ability to disable the feature to add new source files to make. In my case I would never want it to modify the make files, yet with the large number of files, it slows everything down when VGDB does this step.
3. Support for custom commands that can be executed on demand (macros). For instance, if I got all the latest sources for my whole source code tree, I would like to easily press a mapped toolbar button or keyboard combination that runs a pre-configured VGDB command (or list of commands).One can roughly do the same thing by creating multiple VGDB build configurations but this is cumbersome and difficult to maintain.
Thanks for the tip about the environment variables. I played with these and it seems it would do what I want. I have not tried this yet but I assume the environment variables would also work in the SSH Connection Manager?
Once I have everything working, I’ll take a look at the visualizers. I’ve created standard Visual Studio visualizers before and was interested to read the documentation about VGDB’s support for visualizers.
I’ll also be very interested in testing a pre-release version as long as I can go back to a previous version if for some reason it isn’t working properly.
Anyway, VisualGDB is a great product and I’m interested in making it even better… 🙂June 3, 2013 at 05:29 #2435
Thanks for the suggestions, we have added them to our feature plan. For now you can use the following workarounds:
1. To disable an action from a command list you can press the “Copy” button, paste it into a text editor (it will be pasted as XML) and delete it. To get it back simply copy the XML definition back to clipboard and use the “Paste” button.
2. Try using Visual Studio macros to script commonly used commands. You can execute VisualGDB.exe /build file.vgdbsettings to let it run build commands from a given .vgdbsettings file.
We will share a link to the pre-release build in a couple of weeks, but please note that the .vgdbsettings file format has changed significantly and your files will be upgraded when you edit them with the new VisualGDB. To be able to use them with the old version, you will need to backup them.
As for the environment variables in the SSH manager, they may not work out of the box. Please let us know what you are trying to achieve so that we can provide a solution.
You must be logged in to reply to this topic.