Closed rtbo closed 1 year ago
✅ PR OK, no changes in deprecations or warnings
Total deprecations: 15
Total warnings: 0
Build statistics:
statistics (-before, +after)
-executable size=5280736 bin/dub
-rough build time=98s
+executable size=5284832 bin/dub
+rough build time=94s
since you want to ensure that the output doesn't change, do you want to add a test in the tests folder that checks the file to match exactly using diff
?
since you want to ensure that the output doesn't change, do you want to add a test in the tests folder that checks the file to match exactly using
diff
?
The Json file contains the build ID, which varies with compiler version. So I can't predict in a test what the exact content is. At best I can check if all the Json fields are there and the value of the immutable ones.
thanks, seems to be a well designed and useful feature!
Thanks for the quick review !
I've missed the discussion here, but why are we adding JSON files for other tools to depend on ? dub describe
was meant as the way to do this, why is it not enough ?
I'm not sure what "stabilization" means in this context, either. The commit just adds comments.
dub describe
doesn't give any info about cached builds.
e.g. on my system
$ tree ~/.dub/cache/urld
/home/remi/.dub/cache/urld
└── 2.1.1
├── build
│ ├── library-debug-cu9jbmcFOeHiBceMMo2VbA
│ │ └── liburld.a
│ └── library-debug-Z7qINYX4IxM8muBSlyNGrw
│ └── liburld.a
├── db.json
└── db.lock
Meson needs to know what these 2 archives are (compiler, compiler version etc.) in order to use them properly.
Meson uses dub describe
for everything else (import paths, sub-dependencies etc.), but the cache info is not available.
I have to say that enriching dub describe
output would have been a viable option as well (e.g. add the buildId).
I'm not sure what "stabilization" means in this context, either. The commit just adds comments.
What is stable is what should not be changed in future Dub versions.
What is stable is what should not be changed in future Dub versions.
The only thing that should not be changed in future dub version is whatever is part of the API. And the API to access dub's internal data is dub describe
, hence my comment.
I have to say that enriching
dub describe
output would have been a viable option as well (e.g. add the buildId).
I think that might be a better option. But I need to do some reading on the issue(s).
As discussed in #2640, proposal to write Json files in the cache for 3rd party software like Meson to assess compatibility of artifacts in the Dub cache. I've made the choice to write small Json files per package version rather than a gigantic one for the whole cache. This comes at the price of stabilizing the directory structure within the cache (up to where the json file is written).
The PR add the following files in the cache
To ensure interoperability, the following stabilization apply:
$DUB_HOME/cache
default location is stable (env-vars and settings customization still apply)$DUB_HOME/cache
is stableThe final artifact location remains up to Dub developers.
fixes #2640