Works just fine.
I never found that feature in Delphi.
Applause to the Lazarus team !
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Fabio Dell'Aria wrote:
Why is so hard deide to add package support?
I suppose Lazarus would heavily use package support, as with same you
can add custom components without recompiling Lazarus.
So it's important but it needs to be bug free from the start.
-Michael
Michael Schnell schrieb:
Fabio Dell'Aria wrote:
Why is so hard deide to add package support?
I suppose Lazarus would heavily use package support, as with same you
As I said before, I doubt this because it would require that all
packages are compiled separetly for every combination of fpc
This is possible, but it simply doubles the size of the installer.
The FPC Installer ? Same could compile the RTL etc as library and/or as
a package on request (or the user project make process could do this
once it's required).
-Michael
___
Michael Schnell schrieb:
This is possible, but it simply doubles the size of the installer.
The FPC Installer ? Same could compile the RTL etc as library and/or as
a package on request (or the user project make process could do this
once it's required).
Then I don't get why people
Popular business languages (C++, Java, etc.) don't have package
support, so apparently, packages aren't a decision maker for companies
to select their programming language.
Of course, this does not exclude that some Delphi users highly
appreciate the feature, and it could be a significant
Popular business languages (C++, Java, etc.) don't have package
support, so apparently, packages aren't a decision maker for companies
to select their programming language.
Of course, this does not exclude that some Delphi users highly
appreciate the feature, and it could be a
Then I don't get why people refuse that lazarus is recompiled and see
dyn. loaded packages as _the_ solution to this problem :)
Because the make process is just automatic and a not existing package
that needs to be created just adds compile time (once) but does not need
any user actions.
Then I don't get why people refuse that lazarus is recompiled and see
dyn. loaded packages as _the_ solution to this problem :)
Is there another solution that makes it possible to compile and test a
(future) visual component before installing it and with a simple
click-click action add it
Michael Schnell schrieb:
Then I don't get why people refuse that lazarus is recompiled and see
dyn. loaded packages as _the_ solution to this problem :)
Because the make process is just automatic and a not existing package
that needs to be created just adds compile time (once) but does not
Then I don't get why people refuse that lazarus is recompiled and see
dyn. loaded packages as _the_ solution to this problem :)
Is there another solution that makes it possible to compile and test a
(future) visual component before installing it and with a simple
click-click action
Rebuilding/restarting lazarus is also automatic? Do you install daily
packages in lazarus on a Pentium with 128 MB?
I'm not a daily Lazarus user (yet). Maybe I'm still too little trained
on this stuff :(.
-Michael
___
fpc-devel maillist -
Marco van de Voort schrieb:
Then I don't get why people refuse that lazarus is recompiled and see
dyn. loaded packages as _the_ solution to this problem :)
Is there another solution that makes it possible to compile and test a
(future) visual component before installing it and with a
But what is the exact problem with recompiling? Do you install multiple
packages a day ?
Usually you don't.
But if you want to create a visual component, you supposedly need to
install it several times when testing/debugging it.
-Michael
___
On Wed, 2 Jan 2008, Michael Schnell wrote:
But what is the exact problem with recompiling? Do you install multiple
packages a day ?
Usually you don't.
But if you want to create a visual component, you supposedly need to install
it several times when testing/debugging it.
Supposedly
Supposedly ? No, this is not correct. You install once and recompile as much
as needed, that's it.
So you suggest on a future (not too unusual) visual component that all
testing can be done before having it (or the correct version of it) in
the visual component palette ?
Is it possible to
On Wed, 2 Jan 2008, Michael Schnell wrote:
Supposedly ? No, this is not correct. You install once and recompile as much
as needed, that's it.
So you suggest on a future (not too unusual) visual component that all testing
can be done before having it (or the correct version of it) in the
On Wed, 02 Jan 2008 11:34:54 +0100
Michael Schnell [EMAIL PROTECTED] wrote:
Supposedly ? No, this is not correct. You install once and
recompile as much as needed, that's it.
So you suggest on a future (not too unusual) visual component that
all testing can be done before having it (or
When you press 'install' in the package editor, the following happens:
- The IDE calls 'make IDE OPT=-Cn' to compile the IDE (not the
LCL, not any component) without final linking. This is needed for
packages using the IDE sources directly. FPC will only recompile what
has changed.
- IDE
Michael Schnell wrote:
When you press 'install' in the package editor, the following happens:
- The IDE calls 'make IDE OPT=-Cn' to compile the IDE (not the
LCL, not any component) without final linking. This is needed for
packages using the IDE sources directly. FPC will only recompile what
Mattias Gaertner wrote:
On Wed, 2 Jan 2008 11:08:27 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
Then I don't get why people refuse that lazarus is recompiled and
see dyn. loaded packages as _the_ solution to this problem :)
Is there another solution that makes it possible to
Zitat von Marc Weustink [EMAIL PROTECTED]:
Mattias Gaertner wrote:
On Wed, 2 Jan 2008 11:08:27 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
Then I don't get why people refuse that lazarus is recompiled and
see dyn. loaded packages as _the_ solution to this problem :)
On Wed, 2 Jan 2008, Mattias Gärtner wrote:
Zitat von Marc Weustink [EMAIL PROTECTED]:
Mattias Gaertner wrote:
On Wed, 2 Jan 2008 11:08:27 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
Then I don't get why people refuse that lazarus is recompiled and
see dyn.
Zitat von Michael Schnell [EMAIL PROTECTED]:
I developed several visual components for Lazarus and usually you
install once and as you develop is not necessary to recompile the IDE,
but are some exceptions:
1) The installed version crashes the IDE designer
2) You added a published
Designer / popup menu / Change Class
Sounds great !
Thanks !
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Wed, 2 Jan 2008, Mattias Gärtner wrote:
Zitat von Michael Van Canneyt [EMAIL PROTECTED]:
On Wed, 2 Jan 2008, Mattias Gärtner wrote:
Zitat von Marc Weustink [EMAIL PROTECTED]:
Mattias Gaertner wrote:
On Wed, 2 Jan 2008 11:08:27 +0100 (CET)
[EMAIL PROTECTED]
OK, but why on my PC:
ppumove system.ppu
return the following long error:
...
Cannot export fpc_write_text_widestr: symbol not found
Cannot export fpc_writeln_end: symbol not found
Cannot export operatingsystem_result: symbol not found
system.o: In function `SYSTEM_init':
system.pp:1103:
Hi,
can I simply add a bugreport in the Mantis Freepascal site related to this
issue?
2007/12/28, Daniël Mantione [EMAIL PROTECTED]:
Op Fri, 28 Dec 2007, schreef Fabio Dell'Aria:
OK, but why on my PC:
ppumove system.ppu
return the following long error:
...
Cannot export
Op Fri, 28 Dec 2007, schreef Fabio Dell'Aria:
OK, but why on my PC:
ppumove system.ppu
return the following long error:
...
Cannot export fpc_write_text_widestr: symbol not found
Cannot export fpc_writeln_end: symbol not found
Cannot export operatingsystem_result: symbol not found
Op Fri, 28 Dec 2007, schreef Fabio Dell'Aria:
OK, but how I can: Make ppumove dump its linker script and find out what it
does wrong. ?
The -b options return the following .bat file:
That is the correct option.
ld -shared -E -o system.dll system.o
What is at least missing from this
Hi,
this is the results:
ld -shared -E -o system.dll system.o prt0.o
ld: prt0.o: No such file: No such file or directory
2007/12/28, Daniël Mantione [EMAIL PROTECTED]:
Op Fri, 28 Dec 2007, schreef Fabio Dell'Aria:
OK, but how I can: Make ppumove dump its linker script and find out
what
Cannot export fpc_write_text_widestr: symbol not found
Cannot export fpc_writeln_end: symbol not found
Cannot export operatingsystem_result: symbol not found
system.o: In function `SYSTEM_init':
system.pp:1103: undefined reference to `FindResourceA'
system.pp:1103: undefined reference to
But on the wiki I found same ppumove winnt examples:
http://www.freepascal.org/docs-html/user/userse42.html#x149-1490008.7
2007/12/28, Peter Vreman [EMAIL PROTECTED]:
Cannot export fpc_write_text_widestr: symbol not found
Cannot export fpc_writeln_end: symbol not found
Cannot export
Fabio Dell'Aria wrote:
But on the wiki I found same ppumove winnt examples:
http://www.freepascal.org/docs-html/user/userse42.html#x149-1490008.7
I suspect that those docs are outdated. It's been quite some time since
ar.exe needed to be copied to arw.exe or ld.exe needed to be copied to
But if the doc is outdated then an old version works.
Is possible modify the current version to works (as the old version just
done)?
2007/12/28, Andrew Haines [EMAIL PROTECTED]:
Fabio Dell'Aria wrote:
But on the wiki I found same ppumove winnt examples:
At 19:12 28-12-2007, you wrote:
But on the wiki I found same ppumove winnt examples:
http://www.freepascal.org/docs-html/user/userse42.html#x149-1490008.7http://www.freepascal.org/docs-html/user/userse42.html#x149-1490008.7
I've never seen a ppumove created library working under windows.
Ofcourse patches to fpc are welcome if you manage to get packages working.
Or, if the hurdle to that is too large, then research to what is possible
will already help tremendously.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Fabio Dell'Aria schrieb:
Ok but whitout the full package support many companies will never uses
Freepascal because is common think split big application in modules or
simply sell extra application plugins.
What do you think about?
The simple answer is: companies really interested in
Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:
Ok but whitout the full package support many companies will never uses
Freepascal because is common think split big application in modules or
simply sell extra application plugins.
What do you think about?
Popular business languages (C++,
Ok but whitout the full package support many companies will never uses
Freepascal because is common think split big application in modules or
simply sell extra application plugins.
What do you think about?
2007/12/26, Florian Klaempfl [EMAIL PROTECTED]:
Fabio Dell'Aria schrieb:
Ok,but if time
Hi,
2007/12/27, Daniël Mantione [EMAIL PROTECTED]:
Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:
Can I use PPUMOVE tool to simulate basic packages features?
Depends, you can use ppumove to convert units into shared libraries and
you can use such converted units like other units.
Why
Can I use PPUMOVE tool to simulate basic packages features?
2007/12/27, Florian Klaempfl [EMAIL PROTECTED]:
Fabio Dell'Aria schrieb:
Ok but whitout the full package support many companies will never uses
Freepascal because is common think split big application in modules or
simply sell
Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:
Hi,
2007/12/27, Daniël Mantione [EMAIL PROTECTED]:
Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:
Can I use PPUMOVE tool to simulate basic packages features?
Depends, you can use ppumove to convert units into shared libraries and
you can
Can I also dynamically link to all RTL units (system.pp included)?
2007/12/27, Daniël Mantione [EMAIL PROTECTED]:
Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:
Hi,
2007/12/27, Daniël Mantione [EMAIL PROTECTED]:
Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:
Can I use PPUMOVE
Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:
Can I also dynamically link to all RTL units (system.pp included)?
Certainly, but I do not recommend to build a librtl.so containing all rtl
units, as the amount of dependecies will be so huge that it'll be a
challenge to get your program
OK, but the important is that I can do this (using only my needed units).
Is this working on Win, Linux and MacOSX ?
2007/12/27, Daniël Mantione [EMAIL PROTECTED]:
Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:
Can I also dynamically link to all RTL units (system.pp included)?
Certainly,
Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:
OK, but the important is that I can do this (using only my needed units).
Is this working on Win, Linux and MacOSX ?
You will have to check yourself, I can confirm Linux though.
Daniël___
fpc-devel
Hi,
2007/12/27, Daniël Mantione [EMAIL PROTECTED]:
Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:
OK, but the important is that I can do this (using only my needed
units).
Is this working on Win, Linux and MacOSX ?
You will have to check yourself, I can confirm Linux though.
I'm
Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:
Hi,
2007/12/27, Daniël Mantione [EMAIL PROTECTED]:
Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:
OK, but the important is that I can do this (using only my needed
units).
Is this working on Win, Linux and MacOSX ?
You will have to
Yes but I just read the doc and I still obtain the following error:
Processing system.ppu...Error: PPU is already in a library : system.ppu
Linking Error: no files found to be linked
Done.
Why? :(
2007/12/27, Daniël Mantione [EMAIL PROTECTED]:
Op Thu, 27 Dec 2007, schreef Fabio Dell'Aria:
Hi to all and merry xmas,
I have some questions on the 2.4 version.
1)...will be the debug information availables on separated files or
I'll need alway use the strip command to remove them?
2)...will be finally avaiable the packages (as Delphi Bpl) support
(and if yes when will be available the
On 26 Dec 2007, at 18:25, Fabio Dell'Aria wrote:
Hi to all and merry xmas,
I have some questions on the 2.4 version.
1)...will be the debug information availables on separated files or
I'll need alway use the strip command to remove them?
Debug information will still be stored inside the
Why is so hard deide to add package support?
Iss only a new feature, if one do not need it can simply do not use it!
For the debug inforrmation do you think will possible do not include
them directly from compiler increasing optimization level?
2007/12/26, Jonas Maebe [EMAIL PROTECTED]:
On
Op Wed, 26 Dec 2007, schreef Fabio Dell'Aria:
Why is so hard deide to add package support?
Iss only a new feature, if one do not need it can simply do not use it!
It would require to ship the rtl as dynamic library, which is unstable in
its interface, causing DLL hell.
Patches are
On 26 Dec 2007, at 19:58, Fabio Dell'Aria wrote:
Why is so hard deide to add package support?
It's not about deciding, it's about being interested in doing and
maintaining it.
For the debug inforrmation do you think will possible do not include
them directly from compiler increasing
Luiz Americo Pereira Camara schrieb:
Daniël Mantione wrote:
Op Wed, 26 Dec 2007, schreef Fabio Dell'Aria:
Why is so hard deide to add package support?
Iss only a new feature, if one do not need it can simply do not use it!
It would require to ship the rtl as dynamic library, which is
Daniël Mantione wrote:
Op Wed, 26 Dec 2007, schreef Fabio Dell'Aria:
Why is so hard deide to add package support?
Iss only a new feature, if one do not need it can simply do not use it!
It would require to ship the rtl as dynamic library, which is unstable
in its interface, causing DLL
Florian Klaempfl wrote:
Luiz Americo Pereira Camara schrieb:
It would not be possible to ship the compiler and rtl as is today and
let the user/programmer decide if his project will use packages?
Or necessarily, if the change is done, the only option will be use
packages instead of unit
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl wrote:
Luiz Americo Pereira Camara schrieb:
It would not be possible to ship the compiler and rtl as is today and
let the user/programmer decide if his project will use packages?
Or necessarily, if the change is done, the only option
Op Wed, 26 Dec 2007, schreef Luiz Americo Pereira Camara:
Florian Klaempfl wrote:
Luiz Americo Pereira Camara schrieb:
It would not be possible to ship the compiler and rtl as is today and
let the user/programmer decide if his project will use packages?
Or necessarily, if the change is
Daniël Mantione wrote:
Did i miss something, technically? Is necessary to compile with rtl
packages to distribute custom packages?
Yes. Well, unless you want the RTL statically linked into each
package, which will not work in a compatible way due the one
heap/multiple heaps issues.
There
Ok,but if time is the only problem then why do not simple add the
feature in the official and definitive 2.4 roadmap and try to add it
in the next 6/12/24 months?
Is also possible add it as undocumented feature (as generics in 2.2)
in the next 2.4 version and finish its implementation and testing
Fabio Dell'Aria schrieb:
Ok,but if time is the only problem then why do not simple add the
feature in the official and definitive 2.4 roadmap and try to add it
in the next 6/12/24 months?
It increases maintainance time for all future releases and the current
team can't spend more time in
Why is not possible add the package support as is on Delphi (using
Rtl.bpl, Vcl.bpl ...)?
Only if my project is compiled with packajes I must use all base
packages, otherwise I can continue to compile my project as today just
do Freepascal.
2007/12/26, Luiz Americo Pereira Camara [EMAIL
Fabio Dell'Aria schrieb:
Why is not possible add the package support as is on Delphi (using
Rtl.bpl, Vcl.bpl ...)?
Time?
Only if my project is compiled with packajes I must use all base
packages, otherwise I can continue to compile my project as today just
do Freepascal.
2007/12/26,
65 matches
Mail list logo
