Hi,

Many Delphi components are sold as "full source code", or slightly cheaper (or as trial) as compiled *.DCU files for a specific Delphi version.

Could this work with FPC too? Can I release commercial components as PPU files for say FPC 2.6.0 (knowing that those PPU's will not work with any other version of FPC).

The only supported compilers will be the officially released versions.

My concern are platforms like Linux, FreeBSD, where the official release is often is source code format. Would it matter if they compile there own FPC 2.6.0 release, and would my PPU's still work in that case?

Side note:
Personally I'm not a fan of buying components without source code, but sometimes developers are on a shoestring budget, so buying the cheaper (without source code) version is good enough. I would like to cater for those developers too - if possible.

Regards,
- Graeme -

That should work.

My concern are platforms like Linux, FreeBSD, where the official release is often is source code format. Would it matter if they compile there own FPC 2.6.0 release, and would my PPU's still work in that case?

That will most probably not work, although maybe -Ur may provide a solution.

It is a discussion I have had several times, and usually the result was negative. As soon as any of the dependencies is recompiled, there are problems.

Michael.

In our previous episode, Graeme Geldenhuys said:

Could this work with FPC too? Can I release commercial components as PPU files for say FPC 2.6.0 (knowing that those PPU's will not work with any other version of FPC).

(and one set per target)

I've been thinking about this, since the discussion with the TMS grid guy (Bruno F.) on the Lazarus Day. He was interested because of trial versions btw, rather than cheap licenses.

I think it would work in principle. Package built systems are harder though, one doesn't know if they are built with -Ur.

Missing that parameter could mean that a later minor revision of a package (say package 2.6.0-1) has later build dates and will force recompilations.

I have doubts this is all worthwhile. Compared to delphi, versions and targets significalty increase, thus support burden increases (and by that I mean of the binary packaging of the release, not the product) while usage/revenue numbers are nowhere comparable.

The slow refresh of Linux distro's is another problem.

But we'll never know till sb simply tries I guess.

That will most probably not work, although maybe -Ur may provide a solution.

Isn't -Ur a default compiler option in official releases? So a 'make all' in the FPC 2.6.0 source directory should use the same compiler options on every Linux setup etc, and be identical to say the binary FPC 2.6.0 Linux release file. Obviously taking into account the same bit size (32-bit or 64-bit Linux).

Saying that, looking at the released files on SourceForge again - all releases on Linux, FreeBSD etc have binary releases, so maybe the problem is not so much of an issue, because the officially released FPC versions will be consistent across Linux or FreeBSD. And that's the version I'll support in my components. This is just like Delphi then.

It is a discussion I have had several times, and usually the result was negative. As soon as any of the dependencies is recompiled, there are problems.

That's why I'm saying only official FPC releases will be supported in the PPU versions of my components. If they want to use FPC 2.6.x (fixes branch) or FPC 2.7.1, then they must buy the source code version of my components.

I guess the best thing is to simply try it out. Example, using Linux. I'll create PPU on my development machine using an official binary release of FPC 2.6.0. Move those PPU component files to a Linux VM and test it with a binary FPC 2.6.0 release. Then recompile FPC 2.6.0 from official FPC 2.6.0 source archive, and see if my PPU components still work.

Regards,
- Graeme -

Like I said, it may work.
But I think you are in trouble as soon as someone uses e.g. lazarus.

I am not sure whether they use the binary release of fpc, or if they compile their own for e.g. windows. If it is the latter, you're in problems.

IMHO, in the end it is not worth the trouble.

Michael.

Marco van de Voort wrote

(and one set per target)

Correct.

I've been thinking about this, since the discussion with the TMS grid guy (Bruno F.) on the Lazarus Day. He was interested because of trial versions btw, rather than cheap licenses.

Yes, I'm thinking of trial versions too.

I think it would work in principle. Package built systems are harder though, one doesn't know if they are built with -Ur.

Just like my answer to Michael. Isn't -Ur a default compiler parameter set in the Makefiles?

eg: Doing a compile (make all) of 2.7.1
You can see the -Ur is specified by default. I haven't tested FPC 2.6.0, but I think it is the same.

------------------------

me/graemeg/devel/fpc-2.7.1/src/rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE -Fi../inc ../inc/variants.pp
variants.pp(4354,32) Warning: Comparison might be always true due to range of constant and expression
/home/graemeg/devel/fpc-2.7.1/src/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE.
-FU/home/graemeg/devel/fpc-2.7.1/src/rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE ../objpas/types.pp
/home/graemeg/devel/fpc-2.7.1/src/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE.
-FU/home/graemeg/devel/fpc-2.7.1/src/rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE -I../objpas ../objpas/dateutils.pp
/home/graemeg/devel/fpc-2.7.1/src/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE.
-FU/home/graemeg/devel/fpc-2.7.1/src/rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE ../objpas/fgl.pp
/home/graemeg/devel/fpc-2.7.1/src/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE.
-FU/home/graemeg/devel/fpc-2.7.1/src/rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE -Fi../objpas/classes ../unix/classes.pp

------------------------

Missing that parameter could mean that a later minor revision of a package (say package 2.6.0-1) has later build dates and will force recompilations.

That's why I'm thinking of saying "strictly FPC binary releases are supported". This would be no different to Delphi. It's the drawback they must accept when they buy the cheaper version, or using the trial version.

I have doubts this is all worthwhile. Compared to delphi, versions and targets significalty increase, thus support burden increases From my experience it seems that if you do production work, stick to

officially released FPC versions only. I have had problems with 2.7.1 and 2.6.x and reverted to using 2.6.0 only, for production code.

I know this is my experience only - I don't know how other commercial entities work with FPC.

But we'll never know till sb simply tries I guess.

:)

Regards,
- Graeme -

I am not sure whether they use the binary release of fpc, or if they compile their own for e.g. windows. If it is the latter, you're in problems.

Anybody from the Lazarus development team that can comment here?

IMHO, in the end it is not worth the trouble.

I simply want to be as flexible as possible. Without this, I can't supply trial versions of components. Anyway, I'll experiment a bit more using different VM's and report back.

Regards,
- Graeme -

2012/10/22 Graeme Geldenhuys :

I am more optimistic than Michael. Because the same source is used, the CRC is the same and no recompile is done.

So, as long they use unmodified RTL, FCL, (and LCL, if the component depends on it), then there is no problem.

For use in the IDE, the interface of the source should be made available: http://wiki.freepascal.org/Lazarus_Packages#Creating_a_closed_sourced_package

Vincent

DevArt uses this approach for their data access components (see here at the bottom: http://www.devart.com/unidac/compatibility.html ): the binary only trial edition supports a specific version of FPC (2.6.0 currently) and Lazarus (0.9.30.4 currently - seems that the should update ;) ) while general support is available through their source release.

In theory as long as the PPU version (is only changed by breaking changes in the PPU structure, but not within a release), the CPU and the OS (and for ARM and M68k the "FPU emulation setting") is the same and the RTL units are compiled with "-Ur" there shouldn't (!) be much problems. It might (!) get more messy though if you need to use units distributed with Lazarus (e.g. "Controls", "Graphics", etc.), though it could (!) also work without much headaches.

Regards,
Sven

It also depends on the date of the .ppu ?

Michael.

2012/10/22 :

I don't think so. But I don't mind to be proven otherwise.

Vincent

Well, skipping that check is one of the effects of -Ur, if I remember correctly. But one of the compiler gurus can shed light on that :-)

Michael.

Vincent Snijders wrote

I am more optimistic than Michael. Because the same source is used, the CRC is the same and no recompile is done.

Thanks Vincent, things are looking better and better.

Regards,
- Graeme -

You might be interested to follow the forum thread about the Delphi-based Raudus tool (Russian developer) which has a Lazarus port on a closed source binary-only basis.
http://www.lazarus.freepascal.org/index.php/topic,17953.30.html

Howard

Sven Barth wrote

DevArt uses this approach for their data access components (see here at...

Thanks for the info.

problems. It might (!) get more messy though if you need to use units distributed with Lazarus (e.g. "Controls", "Graphics", etc.), though it could (!) also work without much headaches.

The current set of components are all non-visual, so no LCL or fpGUI requirements. I am obviously looking at IDE integration with Lazarus IDE, and thanks to Vincent's wiki link, that doesn't seem doable too.

Regards,
- Graeme -

In our previous episode, Graeme Geldenhuys said:

It seems it is now, the toplevel makefile seems to force it. In the past it only did when RELEASE=1

Note that both Michael and Vincent seem to be right, Michael in that dates are checked, and Vincent that it doesn't matter (because -Ur is used so widely)

I think a careful attempt is the wisest course. But therefore I would start with trials, not binary paid for releases. Just in case you stumble on roadblocks in some popular distro.

Another potential caveat is that many distro systems allow to apply distro specific patches over DIST sources.

>From my experience it seems that if you do production work, stick to officially released FPC versions only. I have had problems with 2.7.1 and 2.6.x and reverted to using 2.6.0 only, for production code.

I can't see why 2.6.0 would be better than fixes branch. Yes, there might be minimal breakage in 2.6.x from time to time, but it also gets you bugfixes earlier, and once a version is stable, you can use it for a while.

As for trunk, that is something completely different.

Marco van de Voort wrote

Another potential caveat is that many distro systems allow to apply distro specific patches over DIST sources.

In that case they will have to use the FPC official 2.6.0 binary release, or purchase the source code version (recommended for obvious reasons).

I can't see why 2.6.0 would be better than fixes branch. Yes, there...

I've had some unexpected issues with 2.6.x - at the time I never knew that new features was also introduced in the fixes branch, not just fixes. The worst case was a few months back when I did a 2.6.x fixes update just before I created new binary releases of our products. ALL our products to 2.6.0 and our products ran
perfectly. Since then all our releases are only done with 2.6.0. Due to time constraints I never investigated what caused the problem in 2.6.x. But two weeks later, 2.6.x (after another fixes update) suddenly worked again. Anyway, it is just easier using an official release we know was well tested.

Regards,
- Graeme -

Am 22.10.2012 15:36, schrieb

The fpc 2.6.0 in lazarus has the same Crc as that one in fpc 2.6.0 (just tested on a randomly selected unit):

c:\>ppudump
c:\entwicklung\lazarus\fpc\2.6.0\units\i386-win32\fcl-web\fphtml.ppu | grep Crc
Uses unit: System (Crc: 6BD71D20, IntfcCrc: 3A58C34A, IndCrc: 615445DA) Uses unit: objpas (Crc: 632812FE, IntfcCrc: 0387260E, IndCrc: 615445DA) Uses unit: Classes (Crc: BB218490, IntfcCrc: 2DEF17D2, IndCrc: B22D8393) Uses unit: sysutils (Crc: 8455ECEA, IntfcCrc: 76A43C16, IndCrc: F7DDC23E) Uses unit: htmlelements (Crc: A4B12E1E, IntfcCrc: 56E40320, IndCrc: 751273A1)
Uses unit: htmlwriter (Crc: 6B16F859, IntfcCrc: 1A1CA7A8, IndCrc: FA677B0C) Uses unit: HTTPDefs (Crc: A716ADEF, IntfcCrc: D213E99D, IndCrc: E368C51E) Uses unit: fphttp (Crc: F26E2B11, IntfcCrc: 88D2B91B, IndCrc: 0E47BE25) Uses unit: db (Crc: 3BC6D223, IntfcCrc: 240C7144, IndCrc: 4A0E76CE) Uses unit: DOM (Crc: 7A25D014, IntfcCrc: FF8CE4B1, IndCrc: 70037A98) Uses unit: contnrs (Crc: F0F5E296, IntfcCrc: 6A65580B, IndCrc: C305805A) Uses unit: WebPage (Crc: 1F66A67B, IntfcCrc: 8851B3A5, IndCrc: 6B3F01C1) Uses unit: XMLWrite (Crc: D83C16B0, IntfcCrc: FED2E472, IndCrc: C22EF90B)

c:\>ppudump c:\pp\units\i386-win32\fcl-web\fphtml.ppu | grep Crc Uses unit: System (Crc: 6BD71D20, IntfcCrc: 3A58C34A, IndCrc: 615445DA) Uses unit: objpas (Crc: 632812FE, IntfcCrc: 0387260E, IndCrc: 615445DA) Uses unit: Classes (Crc: BB218490, IntfcCrc: 2DEF17D2, IndCrc: B22D8393) Uses unit: sysutils (Crc: 8455ECEA, IntfcCrc: 76A43C16, IndCrc: F7DDC23E) Uses unit: htmlelements (Crc: A4B12E1E, IntfcCrc: 56E40320, IndCrc: 751273A1)
Uses unit: htmlwriter (Crc: 6B16F859, IntfcCrc: 1A1CA7A8, IndCrc: FA677B0C) Uses unit: HTTPDefs (Crc: A716ADEF, IntfcCrc: D213E99D, IndCrc: E368C51E) Uses unit: fphttp (Crc: F26E2B11, IntfcCrc: 88D2B91B, IndCrc: 0E47BE25) Uses unit: db (Crc: 3BC6D223, IntfcCrc: 240C7144, IndCrc: 4A0E76CE) Uses unit: DOM (Crc: 7A25D014, IntfcCrc: FF8CE4B1, IndCrc: 70037A98) Uses unit: contnrs (Crc: F0F5E296, IntfcCrc: 6A65580B, IndCrc: C305805A) Uses unit: WebPage (Crc: 1F66A67B, IntfcCrc: 8851B3A5, IndCrc: 6B3F01C1) Uses unit: XMLWrite (Crc: D83C16B0, IntfcCrc: FED2E472, IndCrc: C22EF90B)

So it should be no problem to use units built with units from fpc 2.6.0 with lazarus and the fpc 2.6.0 supplied by lazarus. If no sources are found, the only thing which counts are the CRCs.

-Ur has nothing to do with the CRCs, -Ur avoids only the check if newer sources are available.

Under Linux and Mac you can use ppu compiled for the released fpc 2.6.0 with the Lazarus binaries. I didn't test every ppu and I didn't test Windows.

IMHO, in the end it is not worth the trouble.

Mattias