Re: Captain Jake's Top Ten List of what I'd like to seeinthenextversionofDelphi

John Jacobson wrote:

I see no reason why Delphi can't be distributed with old versions of the RTL
and VCL code in separate directories, ready for the compiler/linker to use when
it encounters an old DCU that was compiled against an old version.

This would have to be extended to more than just the RTL/VCL. Perhaps I have a D6 component library that is compiled against one version of the JCL/JVCL and a D2005 component library that is compiled against a different version of the JCL/JVCL. And I'm using D2008.

I'd need the DCUs for all versions of all units that I needed to compile against. And the linker would need some way to determine which units to link. Right now, the first one found in the library path is the one linked. I suppose you could open the DCU and check it's signature, and if it wasn't the one expected, keep looking for another DCU.

Someone may argue that I could easily install the JCL/JVCL source. But the older version DCU needs the older version of the libraries. Delphi would need the ability to compile code using a compiler compatibility mode for that version (which would also create DCUs for that version). Then the compiler would need to know where to place different versions of the DCU since they can't all sit in one folder.

And while some components may have a single source base for all versions of Delphi, others don't. If you needed to recompile components, you'd need to support the ability of having different versions of the source installed for each version of Delphi, within the same IDE, and an IDE intelligent enough to know where to go for the source.

Something like this would be absolutely awesome for component vendors. I used to have 7 versions of Delphi and 4 versions of C++ Builder installed just to test and build my component for each version.

But I think it's safe to say that you haven't completely thought through the work that would be required to accomplish what you're asking. Not that anyone else has either. But it wouldn't be a small undertaking.
.

Relevant Pages

  • Re: Captain Jakes Top Ten List of what Id like to see in the next version of Delphi
    ... This issue comes up every now and then and the real problem is *not* DCU ... object instance as a set of offsets from a base. ... virtual methods now get layed out starting at index 5 and the field offsets ... compile time and are injected into the intermediate representation which for ...
    (borland.public.delphi.non-technical)
  • Re: enterprise, professional, etc .DCU compatible?
    ... delphi 7, I don't know what version the dcu they want to use was ... I'm trying to help someone using D7 who's getting a compile error. ... installed and the user has all updates installed or vice versa. ...
    (borland.public.delphi.non-technical)
  • Re: enterprise, professional, etc .DCU compatible?
    ... wanted to add that this person is using german version of delphi ... enterprise use the dcu? ... I'm trying to help someone using D7 who's getting a compile error. ...
    (borland.public.delphi.non-technical)
  • Re: enterprise, professional, etc .DCU compatible?
    ... It is Delphi version control:) ... automatically, so if this file in search path, it will disable compiled dcu ... I'm trying to help someone using D7 who's getting a compile error. ...
    (borland.public.delphi.non-technical)
  • Re: crypt(3) in delphi needed
    ... Why don't compile it with C++Builder and result (OBJ, DCU) to be linked ... with Delphi? ...
    (comp.lang.pascal.delphi.misc)