[fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread Graeme Geldenhuys
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 -

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread michael . vancanneyt



On Mon, 22 Oct 2012, Graeme Geldenhuys wrote:


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.


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.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread Marco van de Voort
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)

> 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?

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.

> 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.

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.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread Graeme Geldenhuys
On 2012-10-22 14:15, michael.vancann...@wisa.be wrote:
> 
> 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 -




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread michael . vancanneyt



On Mon, 22 Oct 2012, Graeme Geldenhuys wrote:


On 2012-10-22 14:15, michael.vancann...@wisa.be wrote:


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.


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.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread Graeme Geldenhuys
On 2012-10-22 14:25, 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 -

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread Graeme Geldenhuys
On 2012-10-22 14:36, michael.vancann...@wisa.be wrote:
> 
> 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 -



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread Vincent Snijders
2012/10/22 Graeme Geldenhuys :
> On 2012-10-22 14:36, michael.vancann...@wisa.be wrote:
>>
>> 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?
>

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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread Sven Barth

Am 22.10.2012 15:45, schrieb Graeme Geldenhuys:

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.


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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread michael . vancanneyt



On Mon, 22 Oct 2012, Vincent Snijders wrote:


2012/10/22 Graeme Geldenhuys :

On 2012-10-22 14:36, michael.vancann...@wisa.be wrote:


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?



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


It also depends on the date of the .ppu ?

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread Vincent Snijders
2012/10/22  :
>
>
> On Mon, 22 Oct 2012, 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.
>
>
> It also depends on the date of the .ppu ?

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

Vincent
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread michael . vancanneyt



On Mon, 22 Oct 2012, Vincent Snijders wrote:


2012/10/22  :



On Mon, 22 Oct 2012, 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.



It also depends on the date of the .ppu ?


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


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.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread Graeme Geldenhuys
On 2012-10-22 14:59, 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 -

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread Howard Page-Clark

On 22/10/12 3:17, Graeme Geldenhuys wrote:

On 2012-10-22 14:59, 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.


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

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread Graeme Geldenhuys
On 2012-10-22 15:00, 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 -


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread Marco van de Voort
In our previous episode, Graeme Geldenhuys said:
> > 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?

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)

> > 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 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.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread Graeme Geldenhuys
On 2012-10-22 15:36, 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 crashed at startup. Reverted 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 -

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] releasing commercial components as PPU files

2012-10-22 Thread Florian Klämpfl
Am 22.10.2012 15:36, schrieb michael.vancann...@wisa.be:
>>
>> 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.
> 
> Like I said, it may work. But I think you are in trouble as soon as
> someone uses e.g. lazarus.

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.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal