Delphi Tokyo中运行时包列表为空与指定包的差异咨询

Great question! Let's break down the key differences between these two approaches when building your App.exe (since you're working with Delphi 10.4, given the rtl250.bpl and vcl250.bpl references):

Core Behavior Basics #

First, let's clarify: both scenarios you're describing have runtime packages enabled (otherwise you wouldn't need to deploy those BPLs at all). The difference lies in how the IDE handles your project's dependencies:

• Empty package list: The IDE automatically scans your code and adds all required runtime packages (including rtl250.bpl, vcl250.bpl, and any other packages your code relies on—like FireDAC, Indy, or custom component packages) to the build process.
• Specifying partial packages: You manually list only the packages you want to use as runtime dependencies (in your case, just rtl250.bpl and vcl250.bpl). The IDE won't auto-add any other packages; you have to explicitly include them or statically link their code into the EXE.

Key Differences #

1. Dependency Management: Auto vs Manual Control #

• Empty list: The IDE takes care of dependency tracking for you. If you add a new component (say, a TFDConnection from FireDAC) mid-project, it will automatically add firedac250.bpl and its dependencies to the package list. This is great for rapid development—you don't have to manually track every dependency.
• Partial list: You're in full control. If your code uses functionality from another package, you'll get a compile error unless you either:
  • Add that package to your manual list (requiring you to deploy its BPL), or
  • Disable runtime packages for that specific component/unit (statically linking its code into App.exe instead). This forces you to make intentional choices about what stays in BPLs and what gets embedded.

2. EXE Size & Deployment Footprint #

• Empty list: Your App.exe will be smaller, since most shared code lives in BPLs. But you'll have to deploy all auto-added BPLs alongside the EXE—this can mean a longer list of files to include in your installer or deployment package.
• Partial list: If you only include rtl250.bpl and vcl250.bpl, and statically link all other dependencies, your App.exe will be larger (since it includes the code that would otherwise be in additional BPLs). However, your deployment package only needs those two core BPLs, simplifying distribution.

3. Version Compatibility & Risk #

• Empty list: When you update Delphi or third-party components, the IDE will automatically update the referenced BPL versions. This reduces manual work, but it also means a single incompatible BPL update (e.g., a third-party component breaking changes) could break your entire application.
• Partial list: By limiting runtime packages to only the stable core RTL/VCL, you avoid version conflicts from third-party or custom BPLs. If you static link those components, their code is locked into your EXE at build time, so external BPL updates won't affect your app.

4. Compilation Strictness #

• Empty list: Compilation is more forgiving—you can add code that relies on new packages without worrying about updating the package list. This is ideal for prototyping or projects with frequent dependency changes.
• Partial list: The IDE will throw errors if your code references a package not in your manual list. This enforces strict dependency discipline, which is useful for production projects where you need to tightly control what's included in your deployment.

Why Both Scenarios Require rtl250.bpl and vcl250.bpl #

Your code almost certainly uses core RTL (Runtime Library) and VCL (Visual Component Library) functionality—things like string handling, form creation, and basic UI controls. These are non-negotiable dependencies for any Delphi VCL app using runtime packages, so both approaches will require deploying these two BPLs. The difference is in how other dependencies are handled.

内容的提问来源于stack exchange，提问作者Artisan