search

DelphiPackageManager / PackageManagerRFC

Delphi Package Manager RFC
Apache License 2.0
30 stars 0 forks source link

Package Installation #4

Open vincentparrett opened 5 years ago

vincentparrett commented 5 years ago

Packages will be downloaded and extracted to a Package Cache folder, rather than into each project. An Environment variable (using DPM here, but the name is not decided yet) will expose the package cache folder. A package will update the dproj to add to the base target configuration search paths for the targets supported,

The environment variable would reference the package cache, which would look something like this

so DPM = C:\ProgramData\dpm\Delphi10Tokyo.0\

under that folder would be the platform folders

\Win32 \Win64 ....

Each package would then have a folder, based on the package Id

\DUnitX \Spring.Base \Spring.Core

and inside each package folder, a version folder.

\DUnitX

The following would be added to the Search Path for each package

$(DPM)\$(DPMPlatform)\PackageId\PackageVersion\lib

eg.

$(DPM)\Win32\DUnitX\1.0.2\lib

or

$(DPM)\Win32\Spring.Base\1.2.0\src

The package MetaData file will specify any addition folders that need to be added to the search path. My preference would be for a single folder per package, many third party libraries require far too many paths be added to the libraries or search path in order to use them.

Package installation would determine which platforms a project targets, and which platforms a package supports, and install for supported platforms. In the IDE, options could be provided to not install for a particular platform. This choice should be recorded somewhere (in the dproj, or a packages.config file).

casteng commented 5 years ago

Local cache is necessary but why not to copy package content to projects directory structure? DPM is something like /dpm. Or even /dpm as it's content is temporary and can be redownloaded if needed. For structure I'd suggest \ID\Version\Target This way you may see which platform are supported by particular version of particular package.

vincentparrett commented 5 years ago

My reason for not copying to the project folder is

I'm not dead set against it.. I just want package management to be a simple and fast as possible (because I want faster builds on my CI servers).

code-kungfu commented 5 years ago

A common local repository for the installed packages is key. Also a common directory to store the demos for the components/packs so they're easier to locate (and compile!).

UweRaabe commented 5 years ago

Regarding adding to the Project Search Path: I have a good experience using Option Sets in my projects. Well, after I was able to persuade FinalBuilder to accept them (actually I am resolving them before compiling). I have one option set for each external library I use in the project, which contains merely the search path to the library code (separated by build configuration and platform if needed). The name of the option set indicates the library used (like TMS_Components or Spring4D), so I can directly see the dependencies in the Project Manager view. Adding all the search folders for madExcept, GLScene or TMS Scripter just requires to add the proper option set. These option sets can easily be copied to other projects in the current project group by simple drag and drop. I even use such sets to handle common settings (output and unit output or conditionals) between several projects of a project group. If things have to be changed there is only one place to do so.