Hello,

As part of the Symbian OS port, I wrote an application that works as a build Tool. It handles necessary tasks when building a symbian os application, like definying a UID. Searching for the SDK and interacting with it acording to the SDK version. Calling Fpc, gnu-as and the appropriate linker. Building the c++ to pascal bindings, etc.

So, I was thinking that this software should probably be located on the fpc repository, as it's not possible to use fpc for Symbian without it, but I don't know in which repository and directory I would put it.

By the way, I use lazarus to develop this software, even if it's a command line tool. Can I add a lpi file for it?

Also, where would example applications go?

thanks,

fpcbuild/install/symbianos

By the way, I use lazarus to develop this software, even if it's a command line tool. Can I add a lpi file for it?

You can.

Also, where would example applications go?

fpcbuild/demo/symbianos

Michael.

thanks,

I am downloading fpcbuild repository and something strange happens. It is also downloading a fpcsrc directory that doesn't appear on viewcvs:

http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/?root=fpcbuild

What is that fpcsrc directory? A quick link to the latest fpc release code? It seams to me like the build scripts would use the source on this location, am I right?

Better fpc/utils?

Felipe Monteiro de Carvalho wrote

I am downloading fpcbuild repository and something strange happens. It is also downloading a fpcsrc directory that doesn't appear on viewcvs:

It's an external reference to the fpc repository. You can avoid checking it out by using the svn co option --ignore-externals

What is that fpcsrc directory? A quick link to the latest fpc release code? It seams to me like the build scripts would use the source on this location, am I right?

Yes.

Jonas

Well, if talking about FPC sources (as opposed to
compiled binary), I'd rather expect fpc/utils
(comparable to fppkg, postw32, etc.)?

Tomas

Are the projects on fpc/utils automatically built at some point? (like make cycle or make install) I am wondering that adding mksymbian there with a makefile could cause it to start being compiled on other platforms, where it is useless.

Here is what my makefiles currently looks like:

#
# Makefile.fpc for Free Pascal Symbian Build Tool #

[target]
programs=mksymbian

[clean]
units=cfgfile cmdline compiler constants projectparser sdkutil

[require]
packages=

[compiler]

[install]
fpcpackage=y

[default]
fpcdir=../..

[rules]
.NOTPARALLEL:
mksymbian$(EXEEXT): mksymbian.pas

Felipe Monteiro de Carvalho wrote

Are the projects on fpc/utils automatically built at some point? (like make cycle or make install) I am wondering that adding mksymbian there with a makefile could cause it to start being compiled on other platforms, where it is useless.

A subdirectory is never compiled automatically. So if you add a directory to fpc/utils, you still need to change the fpc/utils/ Makefile.fpc (and regenerated the fpc/utils/Makefile) to build your mksymbian. If you look at fpc/utils/Makefile.fpc, you'll see:

[target]
dirs=fppkg fpcm tply h2pas fprcp dxegen fpdoc
programs=ppdep ptop rstconv data2inc delp bin2obj postw32 rmcvsdir programs_linux=grab_vcsa
dirs_win32=fpmc fpcres
dirs_linux=fpcres
dirs_freebsd=fpcres
rsts=rstconv

So simply add

dirs_symbian=mksymbian

and that directory will only be built and installed for symbian.

Jonas

I think I will leave it without connection to the parent directory. mksymbian is actually compiled for windows when we build fpc for symbian =) so I will handle it's compilation on the build scripts.

I thought it was only needed to build FPC ?

If it is for all kind of programs, then fpc/utils/symbianos is better, indeed.

Michael.

Michael Van Canneyt wrote

I thought it was only needed to build FPC ?

No, it's necessary to build software for symbian os.

The way I designed it you can't simply type: fpc -Tsymbian mysoftware.pas

And expect to have a symbian executable.

This command fails to give enougth information for a real build, which includes the UIDs, if you want to build for the emulator or the real devide, which sdk you are using, where the sdk is located, etc, etc.

Because symbian has many unique things I decided to create a external build tool, which just uses fpc to generate assembler. The other option would be adding lot's of symbian specific options on fpc, but I didn't like this idea.

I think you made a right choice :-)

Michael.

Actually, I could imagine that the final version might be better integrated with FPC for better consistency with other platforms (that certainly doesn't mean that the current solution is wrong - especially considering the current "work in progress" status) and thus possibly higher user-friendliness for FPC users interested in developing for this platform (possibility to use the same configuration files, common documentation of command-line options, no need to install special tools, etc.).

Part of the stuff mentioned above could be probably supported by FPC in a transparent way (paths to SDK libraries and include files, emulator and real device supported as two different targets sharing RTL and most of the platform-specific infrastructure, and possibly others), others could be indeed handled by platform-specific command line options (we already have platform-specific options anyway and it's possible that some of the newly required ones may be re-useable for other current or future target platforms).

Tomas

Tomas Hajny wrote

Actually, I could imagine that the final version might be better integrated with FPC for better consistency with other platforms

Yes, I thougth about that.

But the problem is that on most platforms the unique things are optional. You can write an application without using them, while on Symbian they are mandatory, and you need almost all of them even for a hello world.

One extra factor here: gcc also doesn't work like on other platforms on Symbian. You can't call it directly and expect a symbian software as output. You need to use the special Symbian build system.

Which means that we aren't offering a solution inferior to what gcc provides. I actually consider my build system much better for cross-platform applications, and easier to use, then the standard build system for c++.

Well, I could imagine some solution there as well (e.g. gathering reasonable default values during installation and adding them to the configuration file), but it's obviously up to you, it's meant just as a hint.

BTW, "not getting worse than gcc" is no measure to me. ;-)

Tomas