IDE Issues
in [MFC]
|
From: Joseph M. Newcomer on 4 Mar 2010 18:08 See below... On Thu, 04 Mar 2010 17:45:45 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >Joseph M. Newcomer wrote: > >>> In all honesty, I had this idea once for VS IDE that it would be nice >>> to have a summary output like a pre-MAKE display of: >>> >>> - The files in the project, >>> - dependencies display. >>> >>> Or just for project summary reports. >> **** >> It is really sad that the compiler and IDE really DO have all the information needed for >> this kind of report, but there is nothing that uses it. The silly readme.txt file >> contains nothing worthwhile. > > >Yes, now that is 100% worthless. But its like phishing mail - every >once in awhile I will open it up to see if there anything intelligent >finally added in there. I guess its meant for us to write something. >:) On a related note, what we have in all our project folders are >files with the file name format: > > build#.NEW, e.g.; 4533.new > >Each developer writes his notes using a legend: > > - NEW: A new feature was added. > > - FIX: A fix was performed to an existing feature. > > - ENH: Enhancement to a existence feature. The enhancement may be a > result of a fix to the existing feature or a simple cleanup. > > - CHG: Change to an existence feature behavior. This might be result > or imply an enhancement or a fix. But overall, it is > considered a simple change in behavior concept to an existing > feature. > > - DOC: Documentation item. A new or existing undocumented item is now > documented or expanded. > >Then our build process collects all of these project\build#.NEW files >and makes Addendum Update help pages like so from our last release: > > http://www.winserver.com/public/aup/aup453-3.htm > >I personally go thru them to create a marketing announcement for >sales. Of course, I need to be selective of whats said there >highlighting the NEW, ENH and consolidating the FIX items. Important, >critical fixes are ethically and safely mentioned. :) > >I've use the above legend for my product notes since my first >shareware product in 84. **** When I make changes, I have a REQ.TXT file that assigns a number to each change. For example 4-Mar-10 FIX 007 Modify C.H.A.O.S. interface to support more than one plot to take over the world simultaneously Then at the end of each line I will add (it takes one keystroke!) // REQ #007 Each file has a change log at the front, and it will contain information about the change * 4-Mar-10 | REQ #007: C.H.A.O.S. interface: changed single pointer to std:set At the end, on each release, I have an awk script that lists every change, how many lines changed in the files, what files changed to support the change, etc. For example: ---------------------------------------------------------------------------- REQ #016 | (3) ---------+ ../GraphicCombo.CPP: * 13-Mar-08 | REQ #016: adjust dropdown width ---------------------------------------------------------------------------- REQ #017 | (22) ---------+ ../MainFrm.cpp: * 13-Mar-08 | REQ #017: Handle WM_SYSCOLORCHANGE ../SysColor.cpp: * 13-Mar-08 | REQ #017: Handle WM_SYSCOLORCHANGE ---------------------------------------------------------------------------- REQ #018 | (5) ---------+ ../SysColor.cpp: * 13-Mar-08 | REQ #018: Added new system colors for XP ---------------------------------------------------------------------------- REQ #019 | (1) ---------+ ../StdAfx.h: * 13-Mar-08 | REQ #019: Support through Server 2003 ---------------------------------------------------------------------------- REQ #020 | (196) ---------+ ../Mapping.cpp: * 13-Mar-08 | REQ #020: Added spin controls to the parameters ../XForm.cpp: * 13-Mar-08 | REQ #020: Added spin controls ../Mapping.h: * 13-Mar-08 | REQ #020: Add spin controls to mapping coordinates ../XForm.h: * 13-Mar-08 | REQ #020: Added spin controls ---------------------------------------------------------------------------- It looks better in a fixed-pitch font. Note that some lines might have several changes on them, e.g., // REQ #008 // REQ #022 I need this because it might come back to me two years later and I need to reconstruct what changed for which purpose. From these, I derive the new information needed for customer support people, documentation people, etc. If I have version information (WHY don't we have a build-number incrementer? WHY?) it would appear in the change log, and when multiple people work on a project, the ID of the author of the change normally appears (in this project, I'm the only implementor, so didn't enable the feature). The change logs are maintained by a rich set of editor features which are too painful to add to the VS IDE, but it essentially takes me two keystrokes to create a new change log entry, one keystroke to add a change flag at the end of a line, and two keystrokes plus a couple digits to add a whole slew of change log entries to a block of code. All it requires is to have the right concepts in the editor, and the right primitives in the editor. joe > >> When I get confronted with 100KSLOC from some client project I'm supposed to fix, enhance, >> or rewrite, doing this part of the reverse engineering is one of the difficult tasks. And >> it doesn't have to be. (Note that you can enable a feature that dumps out a #include >> sequence during compilation, but then you have to turn it off again; having a Build>Report >> Structure menu item would be so much easier, and wouldn't have to involve a full rebuild. > > >Yes, I am aware of the pre-processor compiler dump of the includes (if >that is what you are referring to). It is a freaking mess with >redundancy. Passing it thru a filter helps. > >>> How about a Print, Print Preview feature for Solution Explorer? >>> >>> Personally, the build report is useless 80% of the time. It should >>> show date, time, size information to catalog this report. > >> I have found that the build report is useless 99% of the time. > > >Ok, since we just archive the build reports after each release build, >and hardly ever use it (maybe once), I will say its useless 99% time >too. :) > >> And WHY IS is it that after 20 years we STILL do not have an auto-increment-build-number >> capability? The version # (including the current build #) should be in that report! > >I suspect because its really a highly personal thing for development. >It could be optional (OFF by default) and possibly offer a hook into >using a compiled C/C++ DLL and/or VB macro script or something to >customize it. We could not use a simple auto-increment since it would >totally break down our version/framework control/support. But if >customizable, I would consider it for sure. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Mihai N. on 5 Mar 2010 02:54 > (The full path > is not visible in the Solution Explorer or even in the file Properties). Actually, it is in the "Properties" window ("View" - "Other Windows" - "Properties Window", or Alt+Enter in Visual C++ keyboard mapping scheme) -- Mihai Nita [Microsoft MVP, Visual C++] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
From: Mihai N. on 5 Mar 2010 03:07 >:) On a related note, what we have in all our project folders are > files with the file name format: .... > Then our build process collects all of these project\build#.NEW files > and makes Addendum Update help pages like so from our last release: I moved a lot of these tasks to the version control system (perforce) You can create jobs for the various task (can keep your naming convention, looks good), then each code submission can be associated with a job. You can then do a lot of the "magic gathering of release notes" with reports from the version control system. And I bet perforce is not the only one allowing that. -- Mihai Nita [Microsoft MVP, Visual C++] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
From: David Lowndes on 5 Mar 2010 07:06 >it doesn't have to be. (Note that you can enable a feature that dumps out a #include >sequence during compilation, but then you have to turn it off again; having a Build>Report >Structure menu item would be so much easier, and wouldn't have to involve a full rebuild. Submit that one as a suggestion on Connect and post a link back. I'd like to have something like that as well. Dave
From: David Ching on 6 Mar 2010 00:38
"Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in message news:Xns9D31F330B7E38MihaiN(a)207.46.248.16... >> (The full path >> is not visible in the Solution Explorer or even in the file Properties). > > Actually, it is in the "Properties" window > ("View" - "Other Windows" - "Properties Window", > or Alt+Enter in Visual C++ keyboard mapping scheme) > Thanks, I keep forgetting there are two Properties (the modal one and the window). -- David |