Board index » cppbuilder » RADStudio project file annoyances.

2007-12-04 07:02:45 PM
cppbuilder27
I've been trying to sanitize and upgrade some of my projects to
RADStudio 2007 and some upgraded third party component versions, and
here are some of the issues that I keep running into, relating to the
project files (.cbproj) :-
1: There's no way of editing a project file from the IDE. You have to
use notepad.
2: File formatting - newlines aren't inserted in sensible places, so
using notepad is painful.
3: Spontaneous reordering of tags. Whenever I try diffing two project
files, they seem to have had random sections reordered for no reason.
I'm not sure if this is related to RADStudio 'updates' or something
more insidious
4: History lists. Again, these make diffing almost impossible. They
shouldn't be stored in the project file itself. This is QC'd already
5: Duplicate entries in PackageLibs/AllPackageLibs tags. I had one
project file that had literally hundreds of copies of the same ten
packages listed here. Typically, they seem to grow over time for no
obvious reason. Again this makes 'diff' useless!
6: You can't edit the "PackageLibs" and "AllPackageLibs" sections of
the project files from within the IDE. If you replace a package with
another (fred2006.lib vx fred2007.lib) you'll need to manually edit the
project file to sort this.
7: Absolute vs. relative paths. Sometimes I end up with absolute path
references to the project directory (or it's subdirectories) in project
files. This makes moving the project to a different directory difficult.
Items 3,5,6 and 7 happen often, but I haven't got repeatable QC cases
for them yet.
- Roddy
 

Thanks - I was having an "is it just me, or..." moment. I'll add some
QC votes to those reports.
And re. the packagelibs/allpackagelibs things - I'll see if I can find
a repeatable case.
- Roddy
 

project file in BCB6 is possible it is error prone. I have a feeling
someone inside just decided to turn that switch off completely.
small project configuration that is messing this up for you. Do you know
what it is that you do when this starts happening?
This gets added to the include and library paths for me. As a workaround
you can have both the absolute and the relative paths in each path list.
Though, I would like for CodeGear to once and for all **leave the paths
alone** (this has been a problem since BCB4 at least).
Clayton
 

{smallsort}

In article <475541e5$ XXXX@XXXXX.COM >,
"Roddy Pratt" < XXXX@XXXXX.COM >wrote:
are already in QC/RAID, but it won't hurt to put these up as a hit list.
Thanks for your help Roddy.
--
David Dean (CodeGear)
Lead C++ QA Engineer
 

In article <47554cec$ XXXX@XXXXX.COM >,
"Clayton Arends" < XXXX@XXXXX.COM >wrote:
uncheck "Manage include and library paths"
--
David Dean (CodeGear)
Lead C++ QA Engineer
 

Clayton
 

<exit stage left>
 

In article < XXXX@XXXXX.COM >,
"Clayton Arends" < XXXX@XXXXX.COM >wrote:
--
David Dean (CodeGear)
Lead C++ QA Engineer
 

"Roddy Pratt" < XXXX@XXXXX.COM >wrote:
better, even if I have to always edit the changes. But a simple textfile is
easier to maintain than an xml and unfortunately there is no way to create/use a
simple makefile from the IDE anymore.
To be honest, but the VS solution works a way better! Come on Borland - oups CG
- you did already better in the past with BC5.02!
Bob
 

"Bob Gosnell" < XXXX@XXXXX.COM >wrote in message
un-editable and the generated makefiles were all but unreadable.
- Dennis
 

Bob Gosnell wrote:
concerned. The problems we see aren't actually down to the XML format
per se, but down to the /implementation/ of that format. The best
approach is to badger Codegear to fix those implementation details, and
from David's response, I feel we're knocking on an open door.
- Roddy
 

"Roddy Pratt" < XXXX@XXXXX.COM >wrote:
basic functions we already had!
Not having professional features stop me in using it for professional
development - but not the format. Time is against CG, as we and others more and
more move over to VS only because of such silly bugs.
bob