Board index » cppbuilder » Re: Using dual-personality package Delphi/C++ in BDS2006

2006-03-11 03:15:40 PM
cppbuilder85
"Kristofer Skaug" < XXXX@XXXXX.COM >wrote in message
it is a sign that the package (BPI) has not been added to the project.
However, if you are building a standalone exe then it is a sign that the LIB
has not been added to the project. But, it is all speculation until I
download your package and test.
I will be testing this project shortly and will attempt to verify everything
you have posted.
- Clayton
 

I have downloaded, compiled, and installed the package.
First observation: The "Usage Options" for the package was set to
"Designtime only". Since this package contains components that will exist
in an application it should be set to "Designtime and runtime". In general
if the package does not register its own components then set this to
"Runtime only".
Just as you observed the Delphi application that I made can use this
component just fine.
Also, as you observed adding this component to a C++Builder application will
result in the error message:
[Linker Fatal Error] Fatal: Unable to open file 'MYLAB.OBJ'
And, as I suspected in my prior post, it is caused by the BPI not being in
the packages list for the application. Open project options for the app,
click the "Packages" configuration item on the left, and add ";MyComp" to
the end of the "Runtime packages" list. Compile the application again and
it will work fine.
I did not witness the AV so I cannot comment on why it might have happened
to you.
One more suggestion. Be sure that the BPL for the package ends up in one of
the directories in the search path. If it doesn't then the application will
compile just fine (assuming the BPI or DCP file is found) but will not
execute because the OS can't find the BPL.
- Clayton
 

Clayton Arends wrote:
depending on separate runtime packages to be distributed with the exe.
I would not like to have a runtime package (.bpl) floating around on the
search path, separate from the app.
In this situation, should I add the .lib file to the project by hand?
BTW what is the role of the .bpi files (as opposed to .bpl or .dcp)?
in it and was built from a .dpk source originally created in D6.
Unfortunately I am not at liberty to distribute that source - proprietary
company stuff.
But I'll try re-creating the package from scratch in D2006 and let you know
if that helps.
thanks for your help -!
--
Kristofer
 

{smallsort}

In article <4412787d$ XXXX@XXXXX.COM >,
"Clayton Arends" < XXXX@XXXXX.COM >wrote:
for me because it didn't have the nice "Remove this" dialog box that we
now get for ones that are in the project, but not in the paths. I was
always opening project from other people who had different component
sets, and having to remove references from the libs and sparelibs
section of the projects before I could build their projects. Of course,
that doesn't help when you want to add a lib to the project.
--
-David
Nihil curo de ista tua stulta superstitione.
 

"Kristofer Skaug" < XXXX@XXXXX.COM >wrote in message
with runtime packages" check box in "Project | Options | Packages". One
extra step for C++ is to navigate to "Project | Options | Linker | Linking"
and uncheck "Use dynamic RTL". However, you can create a hybrid application
that has to distribute some packages, like vcl.bpl and rtl.bpl, but code
from other packages is linked into the app.
package-based, some that are standalone. And you don't necessarily have to
float the BPL in the search path (like Windows\System32). They can all
exist in the app's directory to be shared just with the EXEs, BPLs, and DLLs
in that directory.
want to use/distribute BPL files. Basically they are .LIB files for the
package system so that the linker knows where to find the exported functions
in the BPL.
point. I have found that many problems go away if I create a new project
file each time I upgrade IDEs. As I have said before, Borland takes care of
most of the upgrade but it's always that last little bit that can cause
unexpected behavior. So, I've made it a habit to always recreate the
project.
- Clayton
 

In article < XXXX@XXXXX.COM >,
David Dean < XXXX@XXXXX.COM >wrote:
attention.
it easy to duplicate, and marked it for attention.
--
-David
Nihil curo de ista tua stulta superstitione.
 

Clayton Arends wrote:
package-based solutions esp. for systems with multiple cooperating
executables - it certainly reduced exe size a lot but your savings have to
overcome the overhead of the bpl's of vcl, rtl etc. Furthermore you have to
overcome the increased complexity of debugging and upgrading code in
packages (change one package and you have to rebuild all dependant exe's),
as well as the impracticality (configuration nightmare) of keeping the
packages anywhere else than in the directory where your exe's are; In the
end I've resigned to the conclusion that life is easier without runtime
packages.
Anyway, I've (finally) good news - I managed to get things working!
With my (proprietary) package rebuilt from a fresh .dpk design-time/runtime
package project in D2006, installing it for Delphi and C++, and running a
test app with one of those components on the form, I now found out how to
avoid the AV during process load, which is to explicitly remove the package
from the runtime packages list in the project options (which was not the
intention anyway). Clearly the path to the runtime (in this case
"$(BDS)\SsbvLib\1.2\") somehow does not get picked up by the de{*word*81}, and
thus the AV results (although I have yet to see a proper error message
saying "the runtime package SsbvLib100 could not be found"!).
At this point I'm afraid I've got to press on (this has cost me too much
time already), so I'll put it down to "don't use runtime package in project
options" as a workaround/fix for this issue. And I suppose I do understand
how to fix it if I really do need to use SsbvLib100 as a runtime package
some day.
As a last confirmation, could you check if you get the same issue with the
"MyComp" package, if you add "MyComp" in the runtime packages list for the
test project?
Thanks again for all your help!
--
Kristofer
 

I keep all of the files generated by the various packages in my system in
the same directory. My structure looks like this:
\comps
\comps\bpl\bds2006
\comps\lib\bds2006 <-- lib, bpi, dcp, dcu, obj
\comps\include\bds2006 <-- for generated hpp files
All component packages are a subdirectory of their own beneath \comps. My
Windows search path only needs to know about the one BPL directory. The
default project options in the IDE only need to know about the one include
directory for includes and the LIB directory for library path.
For packages that are specific to an application the BPI and LIB files are
in the application's search path and not in the \comps path tree.
- Clayton
 

Clayton Arends wrote:
That looks like a 'cleanest possible' solution in light of the
above-mentioned issues.
It doesn't help when there's an important bug fix in e.g. vcl100 (let's say,
BDS2006 SP2)
and you've already deployed apps with the old vcl100... (this happened to me
with D6 and D7).
I prefer to work with strongly 'versioned' directory trees as far as
possible, so that it is explicit and transparent by the path name exactly
which versions of which libraries and executables are being used.
With packages, this is very cumbersome (or inefficient, or both).
--
Kristofer
 

Hi,
was originally written for BCB6 or Delphi6 (and below), so I loaded the
Delphi 6 package with BDS, change all necessary project options and saved it
back as .bdsproj file named NNN_BDS2006.bdsproj. This new .bdsproj compiled
and installed ok. Also I could use all components from the package in Delphi
and C++ Personality of the IDE (Designtime).
So then I created a new project, simple VCL forms application for win32,
with C++ Personality and dropped one of the components from this package on
my new MainForm. When I then tried to start this application (just a form
with one invisible component) I got an AV everytime the IDE tried to start
the application, ending up in CPU debug window. The standard in my BDS is
set to use Runtime packages and compile with RTL. So I changed this to
compile without runtime packages (remove the checkbox in project options
packages) and without dynamic RTL. After this I tried to start the
application again and now - suddenly - the IDE asked me for the package
NNNDelphi6.lib, but I had nothing like this - only NNN_BDS2006.lib.
So I grepped through the source of the package and found in the
NNN_BDS2006.dpk (which is used from NNN_BDS2006.bdsproj internallly) the
line "package NNNDelphi6". Ok, I changed this to "package NNN_BDS2006",
recompiled and installed the new package.
Then the same procedure again and it started without problems - without
runtime packages (static linking) and with runtime packages (dynamic
linking). So maybe you have a similar problem, because you wrote "was built
from a .dpk source originally created in D6" and "In all other Delphi/BCB
compilers I've installed this (since D5/BCB5), it just works right away."
... but maybe here some problem.
Kind regards,
Eike
P.S. The problem with missing .obj files remains - I is very anoying to add
all necessary .lib files to a project (old migrated project from bcb6)...
 

Eike Hoffmann wrote:
thanks for this detailed description. It could indeed be the case that some
internal descriptor is still set to the old package name (I renamed the
package project originally from SsbvLib60 to SsbvLib100). However in the
last attempt I did try a rebuild from new .bdsproj source so this shouldn't
have been possible (unless BDS has even more freaky ghost-memory than we now
suspect). Anyway I'm happy to compile and run without packages because (as I
explained above) I think there are serious deployment/maintenance issues
with this approach.
--
Kristofer