Board index » delphi » Re: bdsproj files

Re: bdsproj files


2004-12-05 11:51:43 AM
delphi65
Paras Kafley writes:
Quote
Well I bet it is not marketing that decided on creating .bdsroj file in
the project directory.
I don't have any problem with that. I just miss an option to disable
them. A little flaw not comparable with those of the marketing staff.
Quote
My inital comments stand -still waiting for a good answer from you.
I think it is obvious from my reply. I keep using Delphi because it's
the best for Win32 development. And I read the newsgroups because is
one of the best places for Delphi-related info.
 
 

Re: bdsproj files

Alvaro GP writes:
Quote
Paras Kafley writes:

>Well I bet it is not marketing that decided on creating .bdsroj file
>in the project directory.

I don't have any problem with that. I just miss an option to disable
them. A little flaw not comparable with those of the marketing staff.

I haven't used D2005 much having only played with the trial- but I bet
there are many people here who have and might be able to explain to you
why Borland thinks the file is important.
no offense but I think it might be better if you try to rephrase your
questions in a slightly different manner in future :-).
~Paras
 

Re: bdsproj files

Alvaro GP writes:
Quote
Paras Kafley writes:


>I don't think the IDE will function properly without this?
>Comments?


It works perfectly without it. In fact, I delete it as soon as I
notice.
Hm.. why not also delete those EXE-files? ALL problems related to D2005
should then go away, absolutely ALL of them.
If BDSPROJ files are stupid, EXE-files are idiotic.
--
Ingvar Nilsen
 

Re: bdsproj files

Ingvar Nilsen writes:
Quote
Hm.. why not also delete those EXE-files? ALL problems related to
D2005 should then go away, absolutely ALL of them.
If BDSPROJ files are stupid, EXE-files are idiotic.
Sounds quite logical :-)
 

Re: bdsproj files

Quote
>There must be pretty good reason for it that is why they put it there.

Not necessarily. Borland does just so many things without a good
reason..
Huh? I'd contend that you simply are not aware of what those "good
reasons" are. In the case of the .bdsproj file, it replaces the .dof file
by using a more open and extensible format (ie. XML). In the future, you
can expect to see more project centric information stored into that file.
Internally, the format is also extensible. Expect to see more APIs show up
in the OTAPI to allow programatic extensions to the project file. The
.local file is for things that are global to a project, but specific to a
user (see the StarTeam integration). Again, these features are in the
initial stages for now, and intend on leveraging them even further in future
releases.
--
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corporation.
blogs.borland.com/abauer
 

Re: bdsproj files

Hi Allen, I am sure that can find an interesting use for .bdsproj files,
but be aware that there are people who don't need it. Why not include
an option to disable the creation of .bdsproj files?
I know people who, as me, delete the .dof files as soon as they appear,
because they are just garbage for them.
 

Re: bdsproj files

Alvaro GP writes:
Quote
Hi Allen, I am sure that can find an interesting use for .bdsproj
files, but be aware that there are people who don't need it. Why not
include an option to disable the creation of .bdsproj files?
I am not on the Delphi team, but I still think I know the answer.
Imagine all the overhead needed to cater for eventualities where the
.bdsproj files are not present, all possible routines that expect this
file to be there.
As Allen says, they plan to extend the OTAPI too, and what then, when
even more functions need this file?
Quote
I know people who, as me, delete the .dof files as soon as they
appear, because they are just garbage for them.
Where do you store the SearchPath information for the project then?
The output directory for your DCU files?
--
Ingvar Nilsen
 

Re: bdsproj files

Ingvar Nilsen writes:
Quote
Where do you store the SearchPath information for the project then?
The output directory for your DCU files?
I don't store a different Search Path for each project. I configure it
globally.
 

Re: bdsproj files

Allen Bauer writes:
Quote
In the case of the .bdsproj file, it replaces the .dof file
by using a more open and extensible format (ie. XML). In the future,
you can expect to see more project centric information stored into
that file. Internally, the format is also extensible.
Lets hope in the future, the command line compiler can also use the
bdsproj instead of requiring a CFG file...
--
** Currently looking for a couple of testers.
** More information in my blog!
+++++++++++++++++++++++++++++++++
Sneak Peek: JED, QC - IDE Edition at
www.alphalink.com.au/~jed/QC/
Blog: jedqc.blogspot.com/
 

Re: bdsproj files

Ingvar Nilsen writes:
Quote
I am not on the Delphi team, but I still think I know the answer.
Imagine all the overhead needed to cater for eventualities where the
.bdsproj files are not present, all possible routines that expect this
file to be there.
I don't think that is a problem for them. In fact, those routines don't
expect that file to be there, because I can delete it at any moment and
still everything works fine.
 

Re: bdsproj files

Alvaro GP writes:
Quote
Ingvar Nilsen writes:

>I am not on the Delphi team, but I still think I know the answer.
>Imagine all the overhead needed to cater for eventualities where the
>.bdsproj files are not present, all possible routines that expect
>this file to be there.

I don't think that is a problem for them. In fact, those routines
don't expect that file to be there, because I can delete it at any
moment and still everything works fine.
Are you running a version of D2005 that doesn't required the .NET
framework though? This could be why.
--
** Currently looking for a couple of testers.
** More information in my blog!
+++++++++++++++++++++++++++++++++
Sneak Peek: JED, QC - IDE Edition at
www.alphalink.com.au/~jed/QC/
Blog: jedqc.blogspot.com/
 

Re: bdsproj files

Alvaro GP writes:
Quote
Ingvar Nilsen writes:


>I am not on the Delphi team, but I still think I know the answer.
>Imagine all the overhead needed to cater for eventualities where
>the .bdsproj files are not present, all possible routines that
>expect this file to be there.


I don't think that is a problem for them. In fact, those routines
don't expect that file to be there, because I can delete it at any
moment and still everything works fine.
Which of course is an evidence that Borland has done a good job, not
that there isn't much overhead involved as I pointed out.
In any case, to me it is a total mystery why anyone would give that file
a second thought at all. For me, the Delhi IDE can create as many config
files it wish, I have plenty of space on my hard drive.
Worrying about that is IMO an absolutely total waste of time.
Files like that are becoming even more common than before I think.
VS.Net has many.
--
Ingvar Nilsen
 

Re: bdsproj files

Alvaro GP writes:
Quote
Ingvar Nilsen writes:


>Where do you store the SearchPath information for the project then?
>The output directory for your DCU files?


I don't store a different Search Path for each project. I configure
it globally.
And thereby putting one of Delphi's gems in the closet.
While you work like that, which seems fine for you, almost anyone else
would use various compiler switches depending on the project, various
search paths and various output and not the least executable directories.
And how on earth do you handle Version Info without the DOF file?
--
Ingvar Nilsen
 

Re: bdsproj files

Ingvar Nilsen writes:
Quote
Which of course is an evidence that Borland has done a good job, not
that there isn't much overhead involved as I pointed out.
Of course, the developer side of Borland has done a good job (I would
say a very good job). I admit that I am too demanding sometimes (that's
because I like Delphi a lot).
 

Re: bdsproj files

Ingvar Nilsen writes:
Quote
And how on earth do you handle Version Info without the DOF file?
Can you be more specific?