Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2008-08

resource support rework

17 messages · 7 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Paul Ishenin

Hello, FPC developers' list

Since resource rework appeared in the trunk we are asking to merge that into fixes branch to let lazarus use it. You told many times that it was imposible for fpc 2.2.2. But yesterday it has been released and what about next fpc version? Will you merge that nice staff into current fixes branch or it will never be merged? I suppose if it ever will be merged then better to merge it early to give enough time for good testing (though lazarus works fine with it).

Best regards,
Paul Ishenin.

Reply by email

Giulio Bernardi
to Paul Ishenin

Paul Ishenin ha scritto:

Show quoted text 10 lines
Hello, FPC developers' list Since resource rework appeared in the trunk we are asking to merge that into fixes branch to let lazarus use it. You told many times that it was imposible for fpc 2.2.2. But yesterday it has been released and what about next fpc version? Will you merge that nice staff into current fixes branch or it will never be merged? I suppose if it ever will be merged then better to merge it early to give enough time for good testing (though lazarus works fine with it).

I wanted to add support for dynamic libraries first. That is, the possibility to retrieve resources from shared objects, and not only from the main program. This currently works for Windows only (obviously, since Win32 API is managing that).
The problem is that currently I'm a bit short of time :(

Giulio

Reply by email

Marco van de Voort
to Giulio Bernardi
Show quoted text 12 lines
Paul Ishenin ha scritto: > imposible for fpc 2.2.2. But yesterday it has been released and what > about next fpc version? Will you merge that nice staff into current > fixes branch or it will never be merged? I suppose if it ever will be > merged then better to merge it early to give enough time for good > testing (though lazarus works fine with it). > I wanted to add support for dynamic libraries first. That is, the possibility to retrieve resources from shared objects, and not only from the main program. This currently works for Windows only (obviously, since Win32 API is managing that). The problem is that currently I'm a bit short of time :(

I think that requires packages, since otherwise:

- both dll and mainapp have own rtl.
- and thus need resources.
- Linux and FreeBSD only have flat linker space ->clash?

Reply by email

Jonas Maebe
to Marco van de Voort
Marco van de Voort wrote 5 lines
I think that requires packages, since otherwise: - both dll and mainapp have own rtl. - and thus need resources. - Linux and FreeBSD only have flat linker space ->clash?

As of FPC 2.2.2, libraries only export the symbols in the "exports" statement on those platforms, so there should not be any clashes.

Jonas

Reply by email

Michael Van Canneyt
to Giulio Bernardi: Paul Ishenin ha scritto: I wanted to add support for dynamic libraries first. That is, the
Giulio Bernardi wrote 16 lines
Paul Ishenin ha scritto: > Hello, FPC developers' list > > Since resource rework appeared in the trunk we are asking to merge that into > fixes branch to let lazarus use it. You told many times that it was > imposible for fpc 2.2.2. But yesterday it has been released and what about > next fpc version? Will you merge that nice staff into current fixes branch > or it will never be merged? I suppose if it ever will be merged then better > to merge it early to give enough time for good testing (though lazarus works > fine with it). > I wanted to add support for dynamic libraries first. That is, the possibility to retrieve resources from shared objects, and not only from the main program. This currently works for Windows only (obviously, since Win32 API is managing that). The problem is that currently I'm a bit short of time :(

Giulio,

I see no problem in merging what exists already, there should not be any problem in merging the additional support later. After all, the case where the resources are in dynamic libraries is rather rare.

Personally, I would be in favour of having it in 2.2.4, it would ensure that it is used.

Michael.

Reply by email

Marco van de Voort
to Jonas Maebe: As of FPC 2.2.2, libraries only export the symbols in the "exports" statement on those…
Show quoted text 10 lines
On 12 Aug 2008, at 08:04, Marco van de Voort wrote: > I think that requires packages, since otherwise: > > - both dll and mainapp have own rtl. > - and thus need resources. > - Linux and FreeBSD only have flat linker space ->clash? As of FPC 2.2.2, libraries only export the symbols in the "exports" statement on those platforms, so there should not be any clashes.

Well, even then you still have two separate states for resources. But that can maybe solved with a hack.

Reply by email

Giulio Bernardi
to Marco van de Voort: I think that requires packages, since otherwise: - both dll and mainapp have own rtl. -…

Marco van de Voort ha scritto:

Show quoted text 18 lines
> Paul Ishenin ha scritto: >> imposible for fpc 2.2.2. But yesterday it has been released and what >> about next fpc version? Will you merge that nice staff into current >> fixes branch or it will never be merged? I suppose if it ever will be >> merged then better to merge it early to give enough time for good >> testing (though lazarus works fine with it). >> > I wanted to add support for dynamic libraries first. That is, the > possibility to retrieve resources from shared objects, and not only from > the main program. This currently works for Windows only (obviously, > since Win32 API is managing that). > The problem is that currently I'm a bit short of time :( I think that requires packages, since otherwise: - both dll and mainapp have own rtl. - and thus need resources. - Linux and FreeBSD only have flat linker space ->clash?

The idea is to be able to generate resource-only shared objects (without any code, I made a proof of concept some time ago and at least for ELF it works), so that programs can load resources from different dlls. For dynamic libraries containing resources, maybe the "dll rtl" can not make use of it and let the main program use it (resources in DLLs are always searched with dlopen/dlsym, so it will be the same, from the main program point of view, if resources are in a resource-only dll or not). This of course until we have packages working.

Giulio

Reply by email

Giulio Bernardi
to Michael Van Canneyt: I see no problem in merging what exists already, there should not be any problem in…

Michael Van Canneyt ha scritto:

Show quoted text 25 lines
On Tue, 12 Aug 2008, Giulio Bernardi wrote: > Paul Ishenin ha scritto: >> Hello, FPC developers' list >> >> Since resource rework appeared in the trunk we are asking to merge that into >> fixes branch to let lazarus use it. You told many times that it was >> imposible for fpc 2.2.2. But yesterday it has been released and what about >> next fpc version? Will you merge that nice staff into current fixes branch >> or it will never be merged? I suppose if it ever will be merged then better >> to merge it early to give enough time for good testing (though lazarus works >> fine with it). >> > I wanted to add support for dynamic libraries first. That is, the possibility > to retrieve resources from shared objects, and not only from the main program. > This currently works for Windows only (obviously, since Win32 API is managing > that). > The problem is that currently I'm a bit short of time :( Giulio, I see no problem in merging what exists already, there should not be any problem in merging the additional support later. After all, the case where the resources are in dynamic libraries is rather rare.

Well, I think there is some delphi code that e.g. use resource-only dlls to store things like localized forms and strings. Ok, there are .po files in lazarus, but the resource thing is meant to ease porting of delphi code too.

Personally, I would be in favour of having it in 2.2.4, it would ensure that it is used.

The only "problem" is that the dynamic library resource support requires some change in the binary format, so I wanted to stabilize it before adding resource support to a stable release.

Giulio

Reply by email

Boian Mitov
to Giulio Bernardi: Marco van de Voort ha scritto: The idea is to be able to generate resource-only shared…

Are there any plans for shared libraries based packages support in the future?

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Earlier message 15 lines
----- Original Message ----- From: "Giulio Bernardi" To: "FPC developers' list" Sent: Tuesday, August 12, 2008 12:17 AM Subject: Re: [fpc-devel] resource support rework > The idea is to be able to generate resource-only shared objects (without > any code, I made a proof of concept some time ago and at least for ELF it > works), so that programs can load resources from different dlls. > For dynamic libraries containing resources, maybe the "dll rtl" can not > make use of it and let the main program use it (resources in DLLs are > always searched with dlopen/dlsym, so it will be the same, from the main > program point of view, if resources are in a resource-only dll or not). > This of course until we have packages working.

Reply by email

Michael Van Canneyt
to Giulio Bernardi: Michael Van Canneyt ha scritto: Well, I think there is some delphi code that e.g. use…
Giulio Bernardi wrote 37 lines
Michael Van Canneyt ha scritto: > > On Tue, 12 Aug 2008, Giulio Bernardi wrote: > > > Paul Ishenin ha scritto: > > > Hello, FPC developers' list > > > > > > Since resource rework appeared in the trunk we are asking to merge that > > > into > > > fixes branch to let lazarus use it. You told many times that it was > > > imposible for fpc 2.2.2. But yesterday it has been released and what > > > about > > > next fpc version? Will you merge that nice staff into current fixes > > > branch > > > or it will never be merged? I suppose if it ever will be merged then > > > better > > > to merge it early to give enough time for good testing (though lazarus > > > works > > > fine with it). > > > > > I wanted to add support for dynamic libraries first. That is, the > > possibility > > to retrieve resources from shared objects, and not only from the main > > program. > > This currently works for Windows only (obviously, since Win32 API is > > managing > > that). > > The problem is that currently I'm a bit short of time :( > > Giulio, > I see no problem in merging what exists already, there should not be any > problem in merging the additional support later. After all, the case where > the resources are in dynamic libraries is rather rare. Well, I think there is some delphi code that e.g. use resource-only dlls to store things like localized forms and strings. Ok, there are .po files in lazarus, but the resource thing is meant to ease porting of delphi code too.

Obviously :-)

Show quoted text 6 lines
> Personally, I would be in favour of having it in 2.2.4, it would ensure > that it is used. The only "problem" is that the dynamic library resource support requires some change in the binary format, so I wanted to stabilize it before adding resource support to a stable release.

You have a point.

Paul, does the new resource scheme already work with lazarus ? If not, maybe you can develop/test it in Lazarus, and during that time Giulio can look at the library support ?

Michael.

Reply by email

Marco van de Voort
to Giulio Bernardi: Marco van de Voort ha scritto: The idea is to be able to generate resource-only shared…
Show quoted text 8 lines
Marco van de Voort ha scritto: > - both dll and mainapp have own rtl. > - and thus need resources. > - Linux and FreeBSD only have flat linker space ->clash? The idea is to be able to generate resource-only shared objects (without any code, I made a proof of concept some time ago and at least for ELF it works), so that programs can load resources from different dlls.

Ok, but that is something else, since then those shared objects have no FPC code, and thus no RTL state.

Show quoted text 5 lines
For dynamic libraries containing resources, maybe the "dll rtl" can not make use of it and let the main program use it (resources in DLLs are always searched with dlopen/dlsym, so it will be the same, from the main program point of view, if resources are in a resource-only dll or not). This of course until we have packages working.

Dealing with these issues is more or less the backbone of packages support.

The rest is pretty much only glueing together on the Pascal (unit) level, and a lot of administration in the compiler.

Reply by email

Paul Ishenin
to Michael Van Canneyt: Obviously :-) You have a point. Paul, does the new resource scheme already work with…
Michael Van Canneyt wrote
Paul, does the new resource scheme already work with lazarus ? If not, maybe you can develop/test it in Lazarus, and during that time Giulio can look at the library support ?

Lazarus already contains a code that can load forms from the native resources (thouse which Giulio have made).

I tested that on win32 and wince and it works fine with lazarus, but have not tried on linux or osx.

Best regards,
Paul Ishenin.

Reply by email

Boian Mitov
to Marco van de Voort: That depends. Do you have some?

Sure do, but will have to seriously be studding the project for a while before I even dare to dip my toe there :-D .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Earlier message 14 lines
----- Original Message ----- From: "Marco van de Voort" To: "FPC developers' list" Sent: Tuesday, August 12, 2008 12:25 AM Subject: Re: [fpc-devel] resource support rework >> Are there any plans for shared libraries based packages support in the >> future? > > That depends. Do you have some? > _______________________________________________ > fpc-devel maillist - > http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Marco van de Voort
to Boian Mitov
Sure do, but will have to seriously be studding the project for a while before I even dare to dip my toe there :-D .

wiki.freepascal.org/packages is pretty much what is already known.

(actually there's a little bit more, some of the compilation problems of the jedi JCL reveal Borlands methods and datastructures for packages)

Reply by email

Martin Schreiber
to Giulio Bernardi: Michael Van Canneyt ha scritto: Well, I think there is some delphi code that e.g. use…
Giulio Bernardi wrote
Michael Van Canneyt ha scritto:

[...]

Show quoted text 9 lines
> I see no problem in merging what exists already, there should not be any > problem in merging the additional support later. After all, the case > where the resources are in dynamic libraries is rather rare. Well, I think there is some delphi code that e.g. use resource-only dlls to store things like localized forms and strings. Ok, there are .po files in lazarus, but the resource thing is meant to ease porting of delphi code too.

MSEgui uses a similar approach with its MSEi18n tool. It uses a custom mechanism instead of resources to store the form data in dynamic libraries. There is an example in apps/i18ndemo.

Martin

Reply by email