Jump to content
aehimself

Splitting existing components to run- and design time packages

Recommended Posts

On 2/8/2021 at 2:11 AM, aehimself said:

* Sigh *

It this as in "I know I'm right so don't confuse me with the facts, sir!"

 

I don't remember any significant use of separate design and run-time packages until Delphi 7. And in those cases, it was because the design-time packages had relatively massive design-time editors and some people didn't want to have the design-time code linked into their run-time EXEs. (You know, all those folks who complain about the size differences in just compiling an empty form and get angry over the steadily increasing size of said units from one release to the next?)

 

Of course, the approach you're suggesting isn't really helping anything. You're oblivious to this since it's just a theoretical question on your part. If you build a package for one project that has certain compiler setting, then try linking the same DCUs into a project that requires different settings, your app may well break. Yes, it compiles just fine. But do you want to be working at a facility that's depending on that code to do something that could cost them tens of thousands of dollars when they find out the code that compiled doesn't produce the correct calculations? Or it prints gibberish text or muddy graphics that are shipped out to customers? Or just doesn't do anything at some point?

 

Some of us have run into this stuff several times in the past when it's NOT "theoretical". When your boss confronts the developer about it, about all they can muster up is ... "well, it seemed like a Good Idea at the time...".


We have a highly distributed platform that was written in 2004 that's starting to spring leaks as it's moved to Windows 10 machines, and over 800 EXEs that run on top of it. Nobody gives a crap about a program that takes 10 additional minutes to render 25,000 invoices, or even how long it takes to run a compile. But when there's garbage printed on 25,000 invoices, somebody is going to get hanged. 

 

And all you have to say when the fallacy of your inquiry is pointed out to you is ... * Sigh *

 

Theoretical discussions are fine. But they're much more interesting when they relate to stuff that actually impacts PRODUCTION processes rather than something nobody would ever seriously do. (Not that people haven't tried...)

 

Share this post


Link to post
9 hours ago, David Schwartz said:

It this as in "I know I'm right so don't confuse me with the facts, sir!"

* sigh *

 

Yes. That was EXACTLY the meaning of it.

Share this post


Link to post
On 2/8/2021 at 3:49 PM, Anders Melander said:

I don't care about the minor improvement in compile speed sharing DCUs can give me. I do care about the time that is wasted when I have to track down some obscure problem caused by using out of sync DCUs.

Let's say I have aeSuperDuperUtilities.pas and I compile it to all platforms, all configs. Then I set my library / debug DCU path to the relevant output folders, browsing path to the source.

If I make a change in said unit, I recompile it again with all platforms / configs.

 

At the moment I cannot imagine a way how any of the compiled DCUs would get out of sync. Then again, most probably I never worked on as many, as complex projects as you did.

Can you please give me a theoretical scenario / direct me to an article so I can learn more about this?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×