Tools. Convert Delphi Project / Units options for the conversion
process
lazarus / 6-IDE-CodeTools

----------------------------------------------------------------------
jmg · 2009-08-14 00:12

The wiki states this ["It asks for a .dpr (Delphi Project) file and
converts it to .lpr; furthermore, it creates the .lpi file and
converts all units. "], but the Project convert step, does convert the
dpr to lpr/lpi, but seems to not 'convert all units' ?
 A separate tool line does that ?

 Having converted some simple projects, and then gone back to make
them Dual-Project, I have some suggestions for this Tool.Convert area
:

a) Add an OPTION to add conditionals, so the units STILL COMPILE in
Delphi. (ie do NOT remove code, or directives, but make them
conditional. Likewise the uses... and Initialize.. areas.
I did all this manually, and was surprised this was not the default.
It should, of course, be smart enough to not add the items, if they
are already there.

b) I could not find a single-button, single pass convert, but it did
all work in Multiple-hops. It seemed to be happier if I sometimes
restarted Lazarus - I think Lazarus Scans-on-load, and (re) organizes
itself better, as a number of messages 'cured themselves'.

 The wiki hints at this here  ["You may also get 'Error reading Form'
messages, click on 'Continue Loading' if you do. "] - that is one
message that seems to go away...

 Perhaps the tools could prompt when this is needed, or launch it
themselves ?

 c) There is a file name conflict on the .res files.
If I relaunch Turbo Delphi on a Lazarus directory, it chokes on the
Lazarus .res file. Manual Delete makes TD recreate a TD version.
It would be nice if that manual delete step was not needed.
 Maybe a "Share with Delphi" project option, that avoids this
name conflict ? Or can the Lazarus file be renamed .resL ?

 Summary: The pieces all work, but they could work better together.

 For a good place for simple Delphi test programs, to test the
conversion tools on, look at
http://www.delphiforfun.org/Programs/index.htm

 I ported two of these with reducing effort each pass, but could
probably do it faster without the tools ....

----------------------------------------------------------------------
Phil · 2009-08-14 00:42

Quote from: jmg on August 14, 2009, 02:12:14 ama) Add an OPTION to add
conditionals, so the units STILL COMPILE in Delphi. (ie do NOT remove
code, or directives, but make them conditional. Likewise the uses...
and Initialize.. areas.

This toolkit is specifically targeted at this type of need, i.e., a
codebase that can be compiled by both Delphi and Lazarus:

http://web.fastermac.net/~MacPgmr/XDev/XDevStatus.html#CodeConverters

Although not specifically stated anywhere that I've seen, I believe
that bringing code into Lazarus is one-way, both with code brought
over from Delphi and the packages of components ported to Lazarus.
This is hard going on those of us who need to remain with Delphi on
Windows. Hence this toolkit.

Thanks.

-Phil

----------------------------------------------------------------------
Phil · 2009-08-14 01:28

Quote from: jmg on August 14, 2009, 02:12:14 am For a good place for
simple Delphi test programs, to test the
conversion tools on, look at
http://www.delphiforfun.org/Programs/index.htm

What a nice set of test programs! I had not heard the name Martin
Gardner in quite some time.

Here's what I did to test one of these, "randomly" selected:

- Downloaded source for Martin Gardner and the "Counterfeit Coin"
Problem.

- Checked that .dfm's are text files. If not, need to convert them
from old .dfm format to text format with Delphi.

- Followed instructions here and converted .dpr, two .pas files for
forms, two .dfm form files to .lfm, then two .lfm's to .lrs:
 
http://web.fastermac.net/~MacPgmr/XDev/XDevStatus.html#CodeConverters

- Opened converted .dpr in Lazarus and let it create a project info
file (.lpi).

- Went to Project | Compiler Options, clicked Parsing and selected
Delphi under Syntax mode (_very_ important to do this when converting
Delphi code - never understood why this isn't the default for all Laz
projects).

- After compiling, made one change to U_Scale.pas uses since this is
not a form code file and so it wasn't converted. Here's the line after
I changed it:

  uses {$IFNDEF LCL} Windows, {$ELSE} LclIntf, SysUtils, {$ENDIF}
classes, controls, comctrls, stdctrls, extctrls, graphics;

- Compiled again and this time it ran. Note that I'm using a Mac, so
this is really quite impressive for Lazarus, wouldn't you say?

- Haven't actually played the game yet but offhand it looks like some
visual adjustments might still be needed, not unusual when running on
a different platform. But at least it compiled and ran with very
little effort.

I was using Laz 0.9.26.2 and FPC 2.2.2 with the Carbon widgetset.

Thanks.

-Phil

----------------------------------------------------------------------
jmg · 2009-08-14 05:59

QuoteThis toolkit is specifically targeted at this type of need, i.e.,
a codebase that can be compiled by both Delphi and Lazarus:

Yes, nice examples, perhaps the IDE should call something like that ?
The IDE does seem inconsistent on the conversion. Sometimes it does
nothing, under Tools.Convert, other times it behaves as expected.

QuoteAlthough not specifically stated anywhere that I've seen, I
believe that bringing code into Lazarus is one-wayYes, hence my
request for the smarter conditional choice.

This type of conversion can be a "converge form both ends" problem, so
being able to run in both is an important step. (if possible).
ie it should not be the simple things that prevent dual-operation.

If you have converted an example, send it to Gary
I converted Roman, Calc, and Pi as 'exercises'

----------------------------------------------------------------------
jmg · 2009-08-14 09:06

I tried the XDev tools, and this is what I found, applying them
to a 'clean' PiCalc (which I know can be converted.)

a) I had to manually remove the $R *.RES in the lpr file. as the
conditional used was true (or, move conditional to IFNDEF LPC)

b) I had to manually add $mode Delphi to match the operation to
the original. Project.Compile.Parser would probably do the same,
but this is a fresh-project pathway, and we cannot rely on user...
(as you say, Delphi should be the default...)
I notice XDev uses
{$IFDEF FPC}
 {$MODE Delphi}
in its own code, but does not insert that into the conversion file.

c) The LazRes seemed to prefer a dfm, not a lfm ?

d) dfmtolfm code gave a warning about StackRec not initialised, and
gave a RTE on a line using StackRec.
[ This on Windows XP, FPC 2.2.?  ]

----------------------------------------------------------------------
Phil · 2009-08-14 15:29

PiCalc1 converted perfectly here, so not sure why you're having any
problems.

Make sure you've converted the .dfm to text format. That may be the
problem you're having with (d)?

I didn't have to do anything with (a). And with (c) you need to
convert the .lfm, not the .dfm, to .lrs.

I suppose DfmToLfm could force Delphi mode with conditionals in the
code. Probably a better solution would be for DfmToLfm just to create
the .lpi file too and set it there. That way it could also set range
checking and overflow checking on by default. (Never understood why
having these off is the default in Delphi and thus in Lazarus too! $R+
is assertions for free!)

Note that PiCalc1 doesn't compile by default in Delphi. Have to check
the Assignable typed constants box.

Thanks.

-Phil


Quote from: jmg on August 14, 2009, 11:06:52 amI tried the XDev tools,
and this is what I found, applying them
to a 'clean' PiCalc (which I know can be converted.)

a) I had to manually remove the $R *.RES in the lpr file. as the
conditional used was true (or, move conditional to IFNDEF LPC)

b) I had to manually add $mode Delphi to match the operation to
the original. Project.Compile.Parser would probably do the same,
but this is a fresh-project pathway, and we cannot rely on user...
(as you say, Delphi should be the default...)
I notice XDev uses
{$IFDEF FPC}
 {$MODE Delphi}
in its own code, but does not insert that into the conversion file.

c) The LazRes seemed to prefer a dfm, not a lfm ?

d) dfmtolfm code gave a warning about StackRec not initialised, and
gave a RTE on a line using StackRec.
[ This on Windows XP, FPC 2.2.?  ]

----------------------------------------------------------------------
Phil · 2009-08-14 17:38

You can post these concerns as one or more bug reports using
Bugtracker link at left. Anything posted on the forum will be lost.

However, keep in mind that the apparent one-way conversion mentality
of Lazarus may be tough to overcome. It looks like they had the idea
that once the code is converted to Lazarus, the developer would just
abandon Delphi or maybe maintain two codebases. That idea seems rather
bizarre.

Thanks

-Phil


Quote from: jmg on August 14, 2009, 07:59:20 amQuoteThis toolkit is
specifically targeted at this type of need, i.e., a codebase that can
be compiled by both Delphi and Lazarus:

Yes, nice examples, perhaps the IDE should call something like that ?
The IDE does seem inconsistent on the conversion. Sometimes it does
nothing, under Tools.Convert, other times it behaves as expected.

QuoteAlthough not specifically stated anywhere that I've seen, I
believe that bringing code into Lazarus is one-wayYes, hence my
request for the smarter conditional choice.

This type of conversion can be a "converge form both ends" problem, so
being able to run in both is an important step. (if possible).
ie it should not be the simple things that prevent dual-operation.

If you have converted an example, send it to Gary
I converted Roman, Calc, and Pi as 'exercises'

----------------------------------------------------------------------
jmg · 2009-08-15 08:40

Some more test results:
i) Yes, you are correct that dfmtolfm coughs on a non-pure-text dfm
file.

However, it turns out Lazarus.Tools.Convert DFM to LFM _is_ DFM format
agnostic : You can convert EITHER a pure TXT,  OR non pure TXT dfm
file.
That detail may help, if you do not have a full Delphi install.
(probably some tips in that tool, to make dfmtolfm tolerate either
file type ? - many will not know what dfm they have )

ii) The Lazres step mentioned (http://web.fastermac.net/~MacPgmr/XDev/
XDevStatus.html#CodeConverters)  is not really needed. A build will
recreate the  .lrs file, PROVIDED your Project Inspector is set up
correctly.

On the present Lazarus, Convert Delphi project does not include LCL,
so a better path is to :
 Create Project from File, and then the Prompt step choice

 Application [Includes LCL], 

occurs and that will create the correct project tree.

You then need to manually add .PAS files to complete that tree.
Other files are created by Build.

eg A correct Project inspector image for PiCalc looks like these 5
lines

File
  PiCalc1.dpr                 //  or can be lpr
  U_PiCalc1.pas             //  this will create .lrs on Build.
Required Packages
  LCL

Summary: Besides the file-switch changes, getting this project build-
ready needed two steps in Lazarus - Create Project from File, and then
Add file (U_PiCalc1.pas here) to Project.
Build will then create all needed files from here.

iii) I changed the MakePasX line ~189 to this
{$IFDEF  DFF_JMG}
        WriteLn(NewFileVar, '{$IFNDEF FPC}');
{$ELSE}
        WriteLn(NewFileVar, '{$IFDEF MSWINDOWS}');
{$ENDIF}

ie mswindows is the wrong 'key', and FPC compiles without manual
edits. On a Mac this may not be noticed

A smarter Lazarus Delphi Project import, that DID add LCL and the
projects units, to the project tree, should not be a lot of work ?

----------------------------------------------------------------------
Phil · 2009-08-15 16:25

Re (i), back around Delphi 6 the text .dfm became the default so any
.dfm files that are still in non-text format are usually very old.
Most developers switched to text format so they could use grep on the
.dfm files, open them in text editors, etc. It looks like some of the
DFF files are circa 2000 so those were probably created with Delphi 5
or earlier.

Re (ii), more recent versions of Laz now automatically create the .lrs
files, meaning the .lrs files are really just artifacts like .o, .ppu,
etc. that can be left behind and not backed up. But it doesn't hurt to
create them.

I suggest you post the IDE concerns as an IDE bug report using
Bugtracker at left. In some cases just thinking through the steps as
you have and clarifying the dialog box labels and messages goes a long
way to making the IDE easier to use. For example, I've always thought
that the File | New choices and their descriptions were extremely
confusing, if not completely muddled. As a newcomer, what do you
think?

Re (iii), not sure what the issue is here. Are you saying that FPC
can't handle Delphi .res files? I think there have been a lot of
changes in the last year or so re. resources, manifest files, program
icon, etc. I can't really keep up on that and there doesn't seem to be
concise documentation on exactly what the current state of all that
is.

Thanks for exercising the XDev Toolkit.

-Phil


Quote from: jmg on August 15, 2009, 10:40:41 amSome more test results:
i) Yes, you are correct that dfmtolfm coughs on a non-pure-text dfm
file.

However, it turns out Lazarus.Tools.Convert DFM to LFM _is_ DFM format
agnostic : You can convert EITHER a pure TXT,  OR non pure TXT dfm
file.
That detail may help, if you do not have a full Delphi install.
(probably some tips in that tool, to make dfmtolfm tolerate either
file type ? - many will not know what dfm they have )

ii) The Lazres step mentioned (http://web.fastermac.net/~MacPgmr/XDev/
XDevStatus.html#CodeConverters)  is not really needed. A build will
recreate the  .lrs file, PROVIDED your Project Inspector is set up
correctly.

On the present Lazarus, Convert Delphi project does not include LCL,
so a better path is to :
 Create Project from File, and then the Prompt step choice

 Application [Includes LCL], 

occurs and that will create the correct project tree.

You then need to manually add .PAS files to complete that tree.
Other files are created by Build.

eg A correct Project inspector image for PiCalc looks like these 5
lines

File
  PiCalc1.dpr                 //  or can be lpr
  U_PiCalc1.pas             //  this will create .lrs on Build.
Required Packages
  LCL

Summary: Besides the file-switch changes, getting this project build-
ready needed two steps in Lazarus - Create Project from File, and then
Add file (U_PiCalc1.pas here) to Project.
Build will then create all needed files from here.

iii) I changed the MakePasX line ~189 to this
{$IFDEF  DFF_JMG}
        WriteLn(NewFileVar, '{$IFNDEF FPC}');
{$ELSE}
        WriteLn(NewFileVar, '{$IFDEF MSWINDOWS}');
{$ENDIF}

ie mswindows is the wrong 'key', and FPC compiles without manual
edits. On a Mac this may not be noticed

A smarter Lazarus Delphi Project import, that DID add LCL and the
projects units, to the project tree, should not be a lot of work ?

----------------------------------------------------------------------
jmg · 2009-08-15 20:03

QuoteFor example, I've always thought that the File | New choices and
their descriptions were extremely confusing, if not completely
muddled. As a newcomer, what do you think?
Certainly there seem to be blind alleys :
eg Convert Delphi Project skips important steps that 'Create Project
from file' includes, and so has the illusion of intelligence.

They also have a strange path on Close Project, which is not the same
as starting a new project with one already open.

One of the more important steps seems to be getting a LCL project
framework, and that choice is not given in many Project pathways,
whilst it should really be the default in all of them.
 The consequence of too many 'uses' is much less severe, than too few!

 Load recent project also MUST have a valid name in the window 
 above, so is a strange gui design where that button is content
conditional, and the others are not.
 If the name is not selected, surely you give the user the select
choice  that's what they are expecting to see next.
 It is, after all, very clear what they want to do....

 Overall, the lowest level stuff seems smart, it is the top-level
menus that needs a clean-up pass, to remove blind alleys.

QuoteAre you saying that FPC can't handle Delphi .res files? I think
in your Mac system that conditional is off, but on windows it is on,
and FPC (IIRC) complains it cannot find the file.

QuoteI suggest you post the IDE concerns as an IDE bug report using
BugtrackerAttempting that now - there seems to be some inertia in the
process...(that, or some pages dislike FireFox...)

QuoteIt looks like some of the DFF files are circa 2000 so those were
probably created with Delphi 5 or earlier.
 It seems loading these into Turbo Delphi and simply saving does not
clean that TXT issue, I had to trawl the menus to find the
dfm choice.
 So, you could maybe add a XDev comment that the IDE.Tools dfm to lfm
does not care.
 I'm not sure if there is a command line path to that Tools converter?

----------------------------------------------------------------------
jmg · 2009-11-05 22:21

An update on this point :

Quote from: Phil on August 14, 2009, 02:42:17 amAlthough not
specifically stated anywhere that I've seen, I believe that bringing
code into Lazarus is one-way, both with code brought over from Delphi
and the packages of components ported to Lazarus.
Just to get a feel for this, I trawled the net, and I found this   
 Pascal Script for Delphi - 3.0.41.79
http://www.remobjects.com/free.aspx

[September 11th Updated release build of the free Pascal Script for
Delphi for Borland Delphi 7, 2007, 2009 and 2010 ]

I downloaded this and fed the .lpx file into lazarus,a nd I got
dozens of files compiled OK, and megabytes of object files created.

So, it seems it is possible to create a file that compiles on a wide
range of Delphi's AND Lazarus/FPC ?

However, when I tried their simple examples, that call these units,
there were parameter errors....

----------------------------------------------------------------------
Leledumbo · 2009-11-06 10:55

QuoteSo, it seems it is possible to create a file that compiles on a
wide range of Delphi's AND Lazarus/FPC ?Only if it's designed
correctly, and AFAIK RemObjects does it quite well. PascalScript runs
on all OSes on i386, but not other processors due to assembler hack.
If only they use pure Pascal code, it may run on all supported
platforms.