Hello listers,

I am blind and I use Freepascal by means of a screen reader. Recently, I and other four blind programers wanted to compile a project which implies the usage of LCL units. The very reduced accessiblity of Lazarus environment make us to decide to compile everything via FPC.

fpc project.pp

Under FPC, it doesn't compile. In spite of the fact FPC is inside the Lazarus, it does not configured to search for LCL units. So we add in fpc.cfg:

-FuC:\lazarus\components
-FuC:\lazarus\components\*
-FUC:\lazarus\lcl
-FUC:\lazarus\lcl\*
-FiC:\lazarus\lcl\include
-FuC:\lazarus\units
-FuC:\lazarus\units\*

The paths were found, but there is a circular reference between messages and lmessages.

Having reported it in a forum, I member told me about lazbuild. I should manually create a XML file with the project settings and try to compile again. The same error about circular reference is raised.

Yes, Lazbuild can be used. But I confess this option strongliy upset me. Lazbuild calls several routines and after all calls FPC. If you imagine the screen reader reads all the output, not having a way to jump the unneeded information, you will evaluate how slow can be the compilation using Lazbuild. The output of FPC is not so verbose, so it's prefferable to use FPC without Lazbuild.

I tried to compile the following example program:

program e026;
{$mode objfpc}{$H+}
uses
interfaces, dialogs;
BEGIN
END.

Under certain point of view, our project has an educational focus. Blind programers with few or any experience is our public. If the first contact with Pascal is complex, people can give up. And the first contact, according this project, implies the usage of LCL. There is a Pascal voice system called Dosvox writen in Pascal. It offers a good set of units for developers. Let me give you an example: the crt unit was converted into dvcrt unit and syntwriteln in place of only show a message, can also speak it.

My conclusion is: I need LCL, but how to compile any code using only Freepascal? How can I configure my fpc.cfg to search for any unit in Lazarus folders and compile any type of project? Console? Graphical?

And to avoid this work, I suggest the standard distribution of Lazarus includes an FPC configured to compile everything.
The ideal would be to do all in the Lazarus interface, but it's impossible. Among other reasons, the label of widgets produced by LCL can't be read by screen readers. But it's subject for another message!

Regards,

luciano de souza wrote

Having reported it in a forum, I member told me about lazbuild. I should manually create a XML file with the project settings and try to compile again. The same error about circular reference is raised.

Probably because your fpc.cfg is processed by lazbuild as well..

Most Lazarus users probably use the IDE, which is obviously an issue. Lazbuild would seem to be the perfect solution then because it is kept up to date with Lazarus changes.

Perhaps it's a good idea to change lazbuild to use a switch (e.g. --quiet or -q) to output less details?

Also, it may be possible to adapt lazbuild to be able to compile your example program (and similar programs) without need for creating an .lpi or .lpr file.
Alternatively, perhaps some wrapper program could be made that does that and calls lazbuild --quiet

let me see if I understood. If I avoid the fpc.cfg processing, probably the compilation will be successful. Should I simply remove fpc.cfg to avoid it?
You say that Lazbuild could be adapted. What does it mean? Should I call some special commandline parameters or Lazbuild should be changed implying an development effort under Lazbuild?
If the reply is that the code of Lazbuild should be changed, regarding I don't know the code of Lazbuild, I prefer to invest in an automatic routine to produce the XML file since it will be simpler for us. But before choosing definetely Lazbuild, let me ask you: configuring properly fpc.cfg, there's no way to compile a project using LCL?

2012/7/25, Reinier Olislagers :

Hi,

You wrote

Under certain point of view, our project has an educational focus. Blind programers with few or any experience is our public. If the first contact with Pascal is complex, people can give up.

I've been working on a Free Pascal educational project for more than four and a half years (it still remains more of a collection of pieces rather than something a new user could start with): http://www.turbocontrol.com/monitor.htm

This wiki page has a little overview from the perspective of an embedded system programmer:
http://wiki.freepascal.org/FPC_Embedded_Nutshell

The project should help provide an easy first contact as shown on this page (there are new tutorials for Win32 users):
http://www.turbocontrol.com/helloworld.htm

The Raspberry Pi is made for educational use and is probably going down in history as the platform that brings many new users to Linux. I'm hoping to help a lot of those folks to consider using Free Pascal. I hope to soon add Python (and maybe other language) versions of a few of the projects so a new user can try different things.

If there are things I can tweak to help you or other blind programmers please contact me. For my direct email go to my home page (below my name below) and use the mailto link and use "office" as the user name.

Regards,
Paul

www.TurboControl.com

luciano de souza wrote

let me see if I understood. If I avoid the fpc.cfg processing, probably the compilation will be successful. Should I simply remove fpc.cfg to avoid it?

If you adapted fpc.cfg, and that doesn't work, that may interfere with lazbuild or Lazarus.
Rather than deleting it, you should undo the changes. You could run fpmkcfg to create a new one if you want to, something like: cd /d c:\freepascal\fpc\2.6.0\bin\i386-win32
fpcmkcfg -d basepath=C:\freepascal\fpc\2.6.0 -o .\fpc.cfg

You say that Lazbuild could be adapted. What does it mean? Should I call some special commandline parameters or Lazbuild should be changed implying an development effort under Lazbuild?

No I mean that there will need to be development effort for this.

If the reply is that the code of Lazbuild should be changed, regarding I don't know the code of Lazbuild, I prefer to invest in an automatic routine to produce the XML file since it will be simpler for us.

If your problem is that you get too much verbose output with lazbuild, generating the lpi file is not going to help you, I think. As far as I know, there is currently no functionality in lazbuild to suppress output messages - but I haven't looked harder than the options list to be honest.

I noticed your demo project which is a .pas file. Lazbuild won't compile that without an lpi thought that it would be a good idea to either:
1. adapt lazbuild so that it can compile regular fpc pas files as well, or
2. create a utility program that generates an lpi (and perhaps an

Obviously, the second option is easier to do, but perhaps the first one is more elegant.

But before choosing definetely Lazbuild, let me ask you: configuring properly fpc.cfg, there's no way to compile a project using LCL?

Sorry, I have not tried that.

Perhaps somebody else and has some suggestions to make.

Regards,
Reinier

Renier,
I will take off the LCL references from fpc.cfg. If it does not work, I will can back to here! Thank you for the help.

Paul,

I thank you for the attention and for the links. I will see them carefully. We want to develop an API for voice access based on an existing project.
The first phase is simply practice Pascal. I think some months will be pass until we have sufficient experience to start. Attatched there is some simple examples. We are producing example codes in other to develop skills. The texts are in portuguese, but we can esasily know what it does. If someone wants to contribute with any example code, I will happy in receiving it.

2012/7/25, Paul Breneman :

The LCL and many other packages require some flags depending on the target platform and build mode. These flags are probably not needed nor wanted by your units. fpc allows to compile different units with different flags.
That's why the LCL is compiled with one call of fpc, which creates a bunch of files for each unit. For example the ppu and o files. They are put into a separate directory, which is called the "output directory" of the package.
Only the output directories of the packages must be added to the search path, not the sources itself. If you add the source directories the compiler may compile the units again, but this time with the wrong flags. Never do that.

Lazarus stores these flags in the lpi and lpk files and automatically compiles the units as needed and in the right order. It checks for consistency too. The IDE has filters to show only the important messages and improves some compiler messages, for example "can not find unit".

lazbuild is a command line tool to compile Lazarus projects and packages. It lacks the ability to filter messages. It simply prints all output of fpc.

If you want to compile any type of project, then you must use lazbuild or the IDE, because some projects need more than a call to fpc.

If you want to compile simple projects, then you can compile a project once. This creates a file projectname.compiled. It contains the command line parameters needed by fpc to compile your project, so you can paste that into whatever IDE you prefer and adjust the verbosity flags of the compiler to your needs.

Mattias

I don't mater with less elegant solutions. The most important is to provide a tool.
yes, I need to read the lpi file. Now I need to understand better how the neeeded structure. lpi files could be complex, but if only a few sections of it is necessary, perhaps, it will be simpler than I can imagine now.
Perhaps, I can execute lazbuild in a TProcess and filter the output to eliminate some unneeded information.
But if someone has an idea how to compile it only with fpc, yes, it would be better.
Thank you!

2012/7/25, luciano de souza :

lazbuild does not read fpc.cfg, but it calls the compiler which reads it.

I guess a simply flag is not sufficient. See the many verbosity flags in the IDE. They were all added on users demand.

Also, it may be possible to adapt lazbuild to be able to compile your example program (and similar programs) without need for creating an .lpi or .lpr file.

Some people suggests to use compiler and IDE directives in the lpr file, which the IDE and lazbuild can use if no lpi is present.

Alternatively, perhaps some wrapper program could be made that does that and calls lazbuild --quiet

Mattias

After reading your message, Mattias, I was persuaded the best solution is to use Lazbuild. We will do a tool to write a lpi. I don't know if I need to write also a lpk file. I suppose these files already exist. Would All the work be to develop the tool to write lpis? Units wsould be compiled in the correct order. Lazbuild can determine which order is that or I need to fill up my lpi with instructions about the order of compilation.
If all the knowledge needed to create this tool is read and write xml, OK, the tool can be done. But if I need to know deeply the flags passed to enqueue units in the correct order, also, the study needs to be much more detailed.

2012/7/25, luciano de souza :

A development effort of lazbuild.

The LCL contains the LCL, the LCLBase and LazUtils. You have to add the three output directories to the unit search path. path_to_lazarus\lcl\units\i386-win32
path_to_lazarus\lcl\units\i386-win32\win32
path_to_lazarus\components\lazutils\lib\i386-win32

You can add them to your fpc.cfg. Note that doing so hides some units with the same name of the fpc installation.

Keep in mind: If you have already compiled with wrong search paths, fpc may have already created ppu files all over the place. So you may have to clean up your installation, which might mean reinstalling Lazarus.

Mattias

After reading your message, Mattias, I was persuaded the best solution is to use Lazbuild. We will do a tool to write a lpi. I don't know if I need to write also a lpk file. I suppose these files already exist.

If you want to share some units across several projects, you can put them into one directory and add a lpk file.
This will speed up the compilation and avoids accidental double creation of ppu files.

For the Lazarus sources all packages already have a lpk file and lazbuild knows where to find them.

Would All the work be to develop the tool to write lpis? Units wsould be compiled in the correct order. Lazbuild can determine which order is that or I need to fill up my lpi with instructions about the order of compilation.

Well, that is the easy part:
The order of units is already figured out by fpc, the order of packages is automatically solved by lazbuild.
Normally it is enough to pass to fpc only the main source file, for instance the lpr file, and some search paths. The compiler will then automatically search and compile all needed units recursively.

If all the knowledge needed to create this tool is read and write xml, OK, the tool can be done. But if I need to know deeply the flags passed to enqueue units in the correct order, also, the study needs to be much more detailed.

Mattias

Sorry, yes, that's what I meant.

True. First user demand for lazbuild though :)

Perhaps we could just pass on -v (and --verbose=) flags to fpc unless no -v flags specified and then use current behaviour? Then we can use -v0 (show nothing except errors) to make lazbuild quieter.

Mmm yes, if we do that we could also move all lpi data into the lpr anyway?

Have just created a simple console project (see below). I suppose lazbuild could perhaps use code from the IDE to create a new blank Program type project, change ProjectOptions & CompilerOptions PathDelim, Title, Unit0 Filename and UnitName, and then save it with the same filename as the .pas file but with .lpi extension, and build it as usual.

Of course, we're in trouble if we specify non-res resources or do more complicated stuff.

Perhaps something like this is best left to a wrapper program?

<?xml version="1.0"?>
<CONFIG>
<ProjectOptions>
<Version Value="9"/>
<PathDelim Value="\"/>
<General>
<Flags>
<MainUnitHasCreateFormStatements Value="False"/>
<MainUnitHasTitleStatement Value="False"/>
</Flags>
<SessionStorage Value="InProjectDir"/>
<MainUnit Value="0"/>
<Title Value="project1"/>
<UseAppBundle Value="False"/>
<ResourceType Value="res"/>
</General>
<i18n>
<EnableI18N LFM="False"/>
</i18n>
<VersionInfo>
<StringTable ProductVersion=""/>
</VersionInfo>
<BuildModes Count="1">
<Item1 Name="Default" Default="True"/>
</BuildModes>
<PublishOptions>
<Version Value="2"/>
<IncludeFileFilter Value="*.(pas|pp|inc|lfm|lpr|lrs|lpi|lpk|sh|xml)"/> <ExcludeFileFilter Value="*.(bak|ppu|o|so);*~;backup"/> </PublishOptions>
<RunParams>
<local>
<FormatVersion Value="1"/>
</local>
</RunParams>
<Units Count="1">
<Unit0>
<Filename Value="project1.lpr"/>
<IsPartOfProject Value="True"/>
<UnitName Value="project1"/>
</Unit0>
</Units>
</ProjectOptions>
<CompilerOptions>
<Version Value="11"/>
<PathDelim Value="\"/>
<SearchPaths>
<IncludeFiles Value="$(ProjOutDir)"/>
</SearchPaths>
<Other>
<CompilerMessages>
<UseMsgFile Value="True"/>
</CompilerMessages>
<CompilerPath Value="$(CompPath)"/>
</Other>
</CompilerOptions>
<Debugging>
<Exceptions Count="3">
<Item1>
<Name Value="EAbort"/>
</Item1>
<Item2>
<Name Value="ECodetoolError"/>
</Item2>
<Item3>
<Name Value="EFOpenError"/>
</Item3>
</Exceptions>
</Debugging>
</CONFIG>

Well... there's still the plan to adapt fpmake so that it can compile the lcl and applications that are using the lcl.

Coincidentally I've worked on that yesterday, and I was surprised how easy it was. I'll continue with it but do not expect that it will become really stable soon....

Joost van der Sluis

[...] > I guess a simply flag is not sufficient. See the many verbosity flags > in the IDE. They were all added on users demand. True. First user demand for lazbuild though :)

Well, not really the first. ;)

Perhaps we could just pass on -v (and --verbose=) flags to fpc unless no -v flags specified and then use current behaviour?

Note: The fpc.cfg normally contains -v flags too.

Mixing human edited content and auto generated
content is asking for trouble.
The session data should never be stored in the source.

Hmm, need some clean up.

Mattias

;)

> Perhaps we could just pass on -v (and --verbose=) flags to fpc unless no > -v flags specified and then use current behaviour? Note: The fpc.cfg normally contains -v flags too.

Ok, but we can't really influence that, nor should we IMO (unless we start filtering stuff etc).
As an aside just found out fpc persists in spitting out everything if both -va -v0 are passed, I'd say that's an fpc design decision. My default fpc.cfg only shows -viwn general info,warnings,notes.

Also, this output would already occur if the OP compiled with FPC instead of lazbuild...

Sorry, that question was ironically meant... as you say, we've got source code and settings separated now which is much better for e.g. version control.

Any opinions on this?