Hi all,

I've made some changes to fppkg to see if it's pssible to make it more suitable for packages for Lazarus.

I've adapted the lnet package so that it installs the lazarus-package files as if they are examples.

If you want to try it, you'll probably have to remove old configuration files (rm -rf ~/.fppkg) and run:

fppkg update
fppkg install lnet

Check if everything is ok with 'fppkg list'

Now the lazarus-lnet-package files are in
~/.fppkg/share/doc/fpc-lnet/lazaruspackage

Maybe we can add scanning of those directories in Lazarus so that packages installed with fppkg which have lazarus-packages with them appear in the packages-installation box?

Maybe that way we can make it attractive to use fppkg to install fpc-additions.

Joost

A good idea.

The original idea I had to make fppkg/fpmake more attractive for the IDE was that there would be a dialog in Lazarus that creates a fpmake.pp from a lazarus package, and that this is used to build.

Secondly, the installer/builder classes in fpmake can be overridden. That means you can actually hook fpmake into the lazarus IDE build system.

These mechanisms are complementary to what you made. I'll see if I can make a proof of concept for the former.

Michael.

Op 2010-09-02 22:05, Joost van der Sluis het geskryf:

I get the following error. I've got latest FPC 2.4.3 in my path under 64-bit Linux.

------------------------------------
~ $ rm -rf ~/.fppkg
~ $ fppkg update
~ $ fppkg list
Name Installed Available
lnet - 0.6.4-2446
~ $ fppkg install lnet
The FPC Package tool encountered the following error: [lnet] Package fcl-process <none> is not available ------------------------------------

BTW:
How can we publish our own package to that list produced by 'fppkg list'. I have been wanting to add fpgui to that list since fppkg came to be.

I think the whole fppkg concept is great (almost like perl's CPAN concept). Unfortunately they FPC rollout of this feature (fppkg and fpmake.pp) is so slow - nearly useless. :-(

Regards,
- Graeme -

The original idea was from CTAN (CPAN for TeX). It is correct that the rollout is slow, but remember that FPC is a small team.

But you are welcome to contribute.

Michael.

Michael Van Canneyt wrote

But you are welcome to contribute.

What is still missing? I'm not referring to Lazarus IDE integration, but rather using fppkg from the command line - so it works on all platforms with any IDE / programmer editor of choice.

The mechanism is basically functional. What needs to be done is using it:

Setting up a server with all packages installed, and testing that.

Michael.

Creating fpmake files is not the problem, imho. Offcourse that could be simplified, but adding the ability to install Lazarus packages at all is now the first step.

That's all not that difficult, but a lot of work, though. ;)

I think that if we can add packages for tiOPF, ZEOS, web-additions, Gecko etc. People will start using it, even if it's interface is somewhat console-based. ;)

Then we can build on that. (But we can do things in parallel, offcourse. ;)

Joost

Michael Van Canneyt wrote

The mechanism is basically functional. What needs to be done is using it: Setting up a server with all packages installed, and testing that.

I don't use 'lnet', but as I mentioned I have been wanting to add packages for ages. fpGUI and as Joost pointed out, tiOPF are the first two on my list. OnGuard and EpikTimer comes to mind as well.

I'll have to read the docs again, but I was under the impression that FPC hosts the server - I just don't know how to submit/upload packages to appear in the 'fppkg list' output. Or is there support for multiple servers pooled together (deb repository style), so I can start hosting my own packages server, but then how is everybody else and fppkg going to know about my server?

Like I said, I need to read the docs again. :)

This (the lazarus addition) only works with 2.5.1. I'll merge it to 2.4.3, but only after I'm sure it won't end up in 2.4.2 at some manner. (Marco?)

This has nothing to do with 2.4.3, but that you have your fpc-installation in a non-default path and fpcsrc not set. (guess, it could also be a bug)

Please set the prefix in the configuration-file to the right value, but on 2.4.3 it will be called BaseInstallDir. (~/.fppkg/config/default)

Then try again.

If this doesn't work try 'fppkg list -v' and see what happens.

BTW: How can we publish our own package to that list produced by 'fppkg list'. I have been wanting to add fpgui to that list since fppkg came to be.

hmm. didn't thought of fpgui.

I think the whole fppkg concept is great (almost like perl's CPAN concept). Unfortunately they FPC rollout of this feature (fppkg and fpmake.pp) is so slow - nearly useless. :-(

Yeah, I think it's a better approach to add third-party packages and maybe move some packages from fpc to this third party packages and let the system mature.

Then later on we can switch parts of fpc itself.

Joost.

You'll have to write them first. I've only written down some basic things.

Multiple repositories and all is possible, but let's keep it simple at start.

You'd better do the same as we did with lnet. Add a fpmake file to tiOPF/fpGUI's repositories. If that works ok. (Check if fpmake archive works, and if you can use that archive to install the package, without any other resources) we can build and add it to the server.

Joost.

no luck yet. I did this... environment variables are case sensitive under linux, so wasn't sure which one, so set both.

opt $ export FPCSRC=/opt/fpc-2.4.3/src
opt $ export fpcsrc=/opt/fpc-2.4.3/src

opt $ fppkg install lnet
The FPC Package tool encountered the following error: [lnet] Package fcl-process <none> is not available

By config file looks as follows:

------------------[ ~/.fppkg/config/default ]------------------------- [Defaults]
ConfigVersion=4
BaseInstallDir=/opt/fpc-2.4.3/x86_64-linux/lib/fpc/2.4.3/ GlobalInstallDir=/usr/local/lib/fpc/2.4.3/
LocalInstallDir={LocalRepository}lib/2.4.3/
Compiler=/opt/fpc-2.4.3/x86_64-linux/bin/fpc
OS=linux
CPU=x86_64
Version=2.4.3
-------------------------------------------------------------------------------

I don't have a GlobalInstallDir, I install FPC to /opt or ~/programming/ I don't know where LocalInstallDir is pointing to, due to the macro.

If this doesn't work try 'fppkg list -v' and see what happens.

This gives no extra output.

$ fppkg list -v
Name Installed Available
lnet - 0.6.4-2446

I thought fppkg was meant for third-party packages primarily. I see the biggest advantage there... easy install of packages not included with FPC. Automatically install package version suitable for your FPC version. No svn or git tools required. No need to go to various download websites. Simply 'fppkg install <packagename>' :-) If it works. ;-)

PS:
Why doesn't fppkg use the GetAppConfigDir() location, which would normally resolve to ~/.config/fppkg/

As far as I know, fpGUI has a working fpmake for quite some time. I even added some usage documentation of fpmake usage too (seeing that I seem to use non-standard paths). I was just waiting on you guys to give me the go-ahead on publishing to the server and what is required from my side. :)

Just tried the 'fpmake archive' command. It failed because fpmake is hard-coded to look for fpmake.pp when the standard pascal extension is .pas. So the FPMakePPFile constant needs to be tweaked a bit. My fpmake file is fpmake.pas, not fpmake.pp

Why does FPC still use .pp anyway? That's from FPC pre v1 days (as far as I remember, from Florian's history lesson).

I was wrong, it's FPCDIR. But this is only used when there's no configuration-file.

As said, update to 2.5.1 and these paths are more logical. But in this case: set GlobalInstallDir
to /opt/fpc-2.4.3/x86_64-linux/lib/fpc/2.4.3/. Remove the baseinstalldir.

GlobalInstallDir and LocalInstallDir are the locations where the installed packages are searched for.

Hmm.. And -d?

It does. Look for ~/.config/fppkg. There you can specify where the {Localrepository} macro is set to. And since it's a repository and not a configuration file, it's location is not in .config by default.

Joost.

I would say: just rename it to fpmake.pp. It will only confuse people if it can ahve two extensions. And what to do if fpmake.pp and fpmake.pas do both exist?

Why does FPC still use .pp anyway? That's from FPC pre v1 days (as far as I remember, from Florian's history lesson).

That's when the current logic was invented: .pas for TP files, .pp for fpc files. Because fpc itself could be compiled using TP.

But that's what we still use: .pp for files which are written for free Pascal and will not run on Delphi. And .pas files for files which will work on both.

Joost.

Nono. .pp is the official Free Pascal source extension.

We support .pas for Dephi/TP compatibility. The compiler uses .pas because initially it was compiled using TP.

Michael.

Michael Van Canneyt wrote

> Why does FPC still use .pp anyway? That's from FPC pre v1 days (as far > as I remember, from Florian's history lesson). Nono. .pp is the official Free Pascal source extension.

Oh? I thought .pp was only used when the language Florian created was still called Pascal++ and the compiler for that language was FPK.

We support .pas for Dephi/TP compatibility. The compiler uses .pas because initially it was compiled using TP.

OK, more information added to my history lesson. :-)

Maybe somebody should notify all authors of text editors like Kate, gEdit etc. to add .pp to the Pascal syntax highlighter filter mask. gEdit to this day doesn't know how to handle .pp files and I have to keep modifying it's configs. The same goes for Midnight Commander's built-in editor. Anyway, I think it's a bit silly using .pp for what is clearly the Object Pascal language. My 2c.

So you suggest changing it to .op ? :)

pp = Pascal Program makes perfect sense.

Actually, using a different extension has it's use, as Joost pointed out. Use .pas if you're sharing code with Delphi, use .pp for FPC-only code.

Michael.

pp = Pascal Program makes perfect sense.

Not really. First program implies binary (at least for me) and second there is usually only one 'program'-file in a pascal application, all other source files are units (leaving out include files as they normally use .inc as extension). I always assumed that the .pp was modelled after .cc for c++ (not used much anymore, I know). pp = pascal program makes some sense but not perfect. :)

How about

ps = pascal source
psf = pascal source file
pp (for program) and pu = pascal unit
psc = pascal source code

Just joking, I don't mind if it is .pas or .pp

Have a nice day
R.

Michael Van Canneyt wrote

So you suggest changing it to .op ? :)

:-)

pp = Pascal Program makes perfect sense.

Not really correct as not every .pp or .pas file is a "program", most are simply pascal units. But at least now I understand why you guys use .pp in FPC source code. As I said, I thought it was simply a "legacy" thing.

Regards,
? - Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

fpGUI now has a fully working fpmake.pp file with unit dependencies. I could successfully do a 'fpmake archive' , unpack in temp folder, 'fpmake build' & 'fpmake install' without problems.

fpmake install did try and install to /usr/local/lib/fpc/2.4.3/units/..../fpgui

which it didn't have write access, so i use -B parameter to redirect it to /opt/fpc-addons/ which worked fine.

I was just about to comment that it would be nice if we could see what version of the package we have installed, then I saw the fpunit.conf file which gives all the details, including a nice checksum. :-) Cool.

One small thing I did notice is the fpmake was not so happy with fpGUI's version numbering. I let fpmake.pp read the version number constant from the fpGUI src directory include file. fpGUI version format is: '0.7.166.g010ab';

0.7 is the major an minor number (the last release). 166 is the number of commits since 0.7 release
g010ab is the commit id (short version of SHA1 identifying specific revision)

Normally a script file automatically generates the version number for me, when I build fpGUI.

fpmake trimmed that version number down to 0.7.0.0

What version number formats does fpmake support. eg: some projects use a date (v0.7-2010-09-03), others use r<subversion_commit> (v0.7.r43234) etc..

So maybe fpmake should be more flexible with the last two areas of the version number? Just a thought.

We thought about that and discarded it, since we need to be able to compare version numbers. With free format that is not possible.

Michael.

Maybe use "half-free" format then:
A version number is a string composed of one or more parts separated by ".".
Each part is either all-digit string or arbitrary string. When comparing version numbers, all-digit parts are compared as integers (e.g. 1 < 10), while parts containing non-digits are compared as strings (e.g. alpha < beta).
Versions are ordered lexicographically as sequences of parts, with leftmost parts deemed most significant.

Michael Van Canneyt wrote

We thought about that and discarded it, since we need to be able to compare version numbers. With free format that is not possible.

Alexander has a point. Even if version numbers are not 100% numeric, they still follow a sequencing order. If all parts are not numeric, simply compare them as strings. Thinking about it, even if all parts are numeric, comparing them as strings should still work (most of the time - if zero padding is used).

Either way, it's not too a big deal for me, I can simply trim the commit ID part and use the version number as 0.7.166.0 for example. Even from that, it is very easy to deduce the actual commit ID in git using the 166 part.

That's why you should use fppkg, and not fpmake directly. (fppkg is in this case only a wrapper, compiling fpmake when necessary and adding default parameters from it's configuration file to fpmake)

With fppkg -v you can see how fppkg calls fpmake.

I was just about to comment that it would be nice if we could see what version of the package we have installed, then I saw the fpunit.conf file which gives all the details, including a nice checksum. :-) Cool.

'fppkg list' scans for all those files and shows which versions are installed.

If uses the same algorithm as Fedora uses for all their packages. And you can imagine how many different version-number-systems there are for all those packages. ;)

In you care the version-number should be: 0.7.166-g010ab.

A subversion-version could be something like (see the lnet package) x.y.z-rxxxx

Joost.

On Fedora they solved that by requiring a numeric, and a free part. And I thought I'd added to fpmake too, But it could be that I missed some parts.

There are three part:
- the version number, ie x.y.z
- The revision number, which is a number just made up to indicate the order of several revisions.
- A free part where you can put anything you want (date, revision number, 'releasecandidate' - anything without a space)

Format is: x.y.z-revnr.anything

If it's a beta-package, without any logical order in between the versions, the revnr should be 0.

Joost