Forum > General
Why Packages are Static Linked!?
systemdesigner:
Hello, I am very new for the forum.
During th last 2-3 years, I have heard and tried Lazarus w/ FPC. I had Delphi past, starting from v6. I think, Lazarus started off with it also. I can say it could be a good alternative to all other popular langs those Java, C#, C++, Ambercedoro X?, Ruby, etc... ıt needs just a little bit energy, horsepower, what else. I see Lazarus as a train running to the future. It has the abilities for being a platform which builds corporate-scaled information systems. I see a chronic problem on the way is "static unit/package linking". Delphi had done a method "LoadPackage" many years ago! Then this made it a corporate system builder. When I add a package to Lazarus ide, it builds itself and restart. Who designed or decided this model!? Or what about "LoadPackage" on runtime!? Corporate systems must consist of building blocks, what about Lazarus or its products? How could the designers make it such "static"!? Lazarus runs to the future, but designers on the train, runs to the past!? This century of information, everything becomes like a "lego" part; plug or remove and play; so why not Lazarus!? It supports platforms and systems much than its competitor alternatives do... It has the chance to become the best, it needs its designers to run with it to the future. Thanks.
Thaddy:
There is currently a lot of effort to mitigate that issue.
That's not easy. The way Delphi does it is patented. Even MS code doesn't come close to that.
As I understand it, compiler devs are really making an effort to implement a similar approach without infringing that patent(s).
Note that in principle you can already compile shared code into a shared library on most platforms FPC supports.
Note that NONE of the languages you mention have a truly two way integrated and synchronized solution between visual design and sourcecode.
They say they have, but that's a big commercial for something that isn't there...
Only Delphi and Lazarus have that - the component model. Delphi in a dynamic way, Lazarus will have that too in the future.
marcov:
(personally, , I rather keep the current way. I install a package much less often than I start lazarus and Delphi's relative slow start is due to packages.
I don't see that much advantage in dynamic packages in the IDE anyway. Delphi chose that way because the Lazarus way is not feasible for a closed source project.
For own modular projects I can imagine some use, but not for the IDE. See also http://wiki.freepascal.org/packages#Lazarus_and_Library_packages for some more discussion (most notably the versioning paragraph))
Thaddy:
I fully agree. It may also lead to the misgiven "compile with packages" option hell. Frankly I am also Ok with how it is now. As you write: you do not install/uninstall packages on a daily basis.
avra:
--- Quote from: systemdesigner on June 28, 2017, 11:51:57 pm ---Corporate systems must consist of building blocks, what about Lazarus or its products? How could the designers make it such "static"!?
--- End quote ---
That is exact first thought of almost everyone comming from the Delphi world, including myself. However, you should think about this for a moment. Delphi had releases about once a year. And all component vendors had to update their components for each version they wanted to support. We all remember trouble even when we had a source but our Delphi version didn't match versions supported by component creator. Even service packs on Delphi were rare because you would also need to support each service pack with your component. Also, as a component creator this, besides lots of work, would mean that you would need to buy and own each Delphi version you wish to support. That was too much for many component creators and only big ones followed this model. Now imagine Lazarus. Current official version is 1.6.4. Before that were 1.6.2 and 1.6.0 and soon 1.8.0 will follow. Besides this, Lazarus and FPC developers have trunk versions built on a daily bases, and these are a moving target which really can't be followed by the Delphi model you wish for. At best only official versions can be supported. People are working on such feature and that is going to happen. However it is going to be of limited use, since all bugs solving is happening in trunk. And believe me, you will want to be involved in that sooner or later. Either as a developer or at least as a tester of the bug you reported or a feature you asked for. That power is not available in Delphi. And it never will be. Period.
Navigation
[0] Message Index
[#] Next page