| T O P I C R E V I E W |
| bta |
Posted - Dec 16 2016 : 07:06:46 AM
I really like the VA View 'included by' tree.
I use it quite a lot to see how big my next compilation would be.
However because it can be included by other headers that again are included by other files,
it is hard to see the exact impact of changing the header.
Ideally I would like to see the total number of impacted files right next to the 'included by' item. (and maybe even next to each header item in the complete tree)
Of course I can't estimate the performance impact if this, but it would be very helpful!
Bart |
| 3 L A T E S T R E P L I E S (Newest First) |
| accord |
Posted - Dec 20 2016 : 7:41:02 PM
This "Expand Descendants and Copy" can be really slow in large projects (sometimes even a progress dialog appears where you can cancel) so I don't think showing the numbers would be feasible. |
| bta |
Posted - Dec 19 2016 : 08:16:24 AM
There are a few reasons (all related to developer efficiency), which are maybe specific to the way of working in my company...
We have multiple products that all share code (so called 'tools') to some degree.
We all continuously work on the same branch of that code base.
The developers working on that common codebase (tools), will of course do refactorings that might brake (compilation/linking and functional) any of the products.
That's why they typically (to avoid broken builds, ...) work on a project that includes the codebase of all the products, so they can see and investigate the full impact of a change.
We also have a custom build system which lacks some knowledge about what files actually are required for a specific exe, in the sense that it (simplified) contains the following phases: compile everything, make all dlls, link all exe's.
(only when a phase if fully completed, it goes to the next phase)
That means that 1 little change in a header could trigger a build of 30+ min.
As developing is a typical iterative process, it sometimes makes sense to first do the change in the smallest product only (separate checkout), until it works there, and only then migrate the changes to the full codebase.
Note that a 'tools'-developer doesn't always know what compilation impact a header file from a specific product has, meaning that it might look like a small change for him (when looking at the tools headers), but a significant part of a product might have to be rebuild (I'm exaggerating here of course...).
As the default is to work on the 'master of all projects' project, you only switch to that separate project approach when it makes sense. So here is where seeing the impact helps: help to make the decision to stay in the big project are move to a smaller one first...
Your workaround does the trick (thanks, didn't seem to notice the copy part) but, as you said, its an extra manual step to perform... |
| feline |
Posted - Dec 19 2016 : 06:15:19 AM
Apart from the curiosity value, how will this actually help? If you are modifying any widely used header file, then you already know you are in for a large re-compile.
If you just want to check the number of files occasionally, or for a few special cases, you can right click and use:
VA View -> Right Click -> Expand Descendants and Copy
on the "included by" node. Pasting this into a text editor, or a text file in the IDE will give you a line count, which is the number you are interested in. A manual approach, but it is a possible work around. |
|
|
