Re: Delphi language support in CMake build system
- From: Rob Kennedy <me3@xxxxxxxxxxx>
- Date: Sat, 18 Oct 2008 00:53:15 -0500
eric.lemings@xxxxxxxxx wrote:
Cross-posted from CMake's mailing list <http://www.cmake.org/pipermail/
cmake/2008-October/024670.html> so that Delphi experts might possibly
answer the "intermediate translation" problem below:
Alan W. Irwin wrote:On 2008-10-16 18:08-0600 Eric (Brad) Lemings wrote:Where can I find info/tutorials on adding support for new languages to
CMake?
The following is pretty minimal, but I think this is all there is at the
moment.
Look at Modules/CMakeAddNewLanguage.txt in the CMake source tree. Pick a
language you are familiar with and uses its support files in Modules and
Modules/Platform as a template for your own work. You may also want to
look
at the CMake source code to confirm how CMake interacts with those
various
language support files. Ask for help on this mailing list when you run
into some difficulty.
Delphi, as I've just discovered, is quite different from the familiar
C/C++ compile/link phases assumed by CMake. For example, different
types of Delphi source files produce different types of output files
as shown below:
C:\Temp>dir /b
a.pas
b.pas
c.pas
d.dpr
C:\Temp>type a.pas
package A;
end.
Packages go in DPK files.
C:\Temp>type b.pas
library B;
begin
end.
DLLs go in DPR files.
C:\Temp>type c.pas
unit C;
interface
implementation
end.
That one's OK.
C:\Temp>type d.dpr
program D;
begin
end.
That one's good, too.
But yes, your point remains: There is not a one-to-one correspondence between primary input file extension and primary output file extension. A DPR file can yield either an EXE file or a DLL. (Or anything else, really. See the $OUTPUTEXT compiler directive.)
C:\Temp>dcc32 a.pas b.pas c.pas d.dpr
CodeGear Delphi for Win32 compiler version 18.5
Copyright (c) 1983,2007 CodeGear
a.pas(2)
b.pas(3)
c.pas(4)
d.dpr(3)
16 lines, 0.14 seconds, 10980 bytes code, 12152 bytes data.
C:\Temp>dir /b
a.bpl
A.dcp
a.dcu
a.pas
b.dll
b.pas
c.dcu
c.exe
c.pas
d.dpr
d.exe
In particular, I know of no way to translate a Delphi program into an
intermediate form before linking the executable. (I'll readily admit
to knowing very little about Delphi though.) So I'm not sure how to
make CMake aware of this.
What, in particular, does CMake need to be aware of?
If you just give dcc32 the names of your project files, it will go out and compile the units it needs. (In fact, as you can see from the output of c.pas, it looks like dcc32 can get a little confused if you ask it to compile standalone units.) You don't need an external build system to determine which of your units have been modified and which units depend on them, or to compile each of those units separately. Delphi's compiler does all that for you, not just by looking at file timestamps, but by checking whether the interfaces of units have changed.
Tackling the problem from a different angle, Delphi's native build
system is based on MSBuild.
As of Delphi 2007. Prior to that, it's just dcc32 interpreting the DPR or DPRPROJ file.
--
Rob
.
- Follow-Ups:
- Re: Delphi language support in CMake build system
- From: Marco van de Voort
- Re: Delphi language support in CMake build system
- From: eric.lemings@xxxxxxxxx
- Re: Delphi language support in CMake build system
- References:
- Delphi language support in CMake build system
- From: eric.lemings@xxxxxxxxx
- Delphi language support in CMake build system
- Prev by Date: Re: Testing Delphi DLL crashes VB6 IDE
- Next by Date: Re: Pascal analyzer - Yacc?
- Previous by thread: Re: Delphi language support in CMake build system
- Next by thread: Re: Delphi language support in CMake build system
- Index(es):
Relevant Pages
|
