I have examined the packages in OPM, A..F and found three that will not work my proposed model (of guessing top of package tree using OtherUnitFiles). And found several more that would not work if some Examples were later added in the most sensible place.
So, that means it needs to be done the hard way. Here is my plan -
- First we test for <ExamplesDirectory Value="XXX"/> in the LPK file. If we find it, use it as authorative. Looks like this eg -
<?xml version="1.0" encoding="UTF-8"?>
<CONFIG>
<Package Version="5">
<Name Value="NewPackage"/>
<Type Value="RunAndDesignTime"/>
<ExamplesDirectory Value="../"/>
- Failing the above, we try the guess model using OtherUnitFiles, that will work for the majority of existing packages, is easily and quickly done and will allow most packages to work without rebuilding (or editing) the existing LPK file.
Maintainers of packages can then choose how they wish to make their package compliant, for many, it will be just a case of adding meta data files, only a few will need to force the issue with the first option.
OK, now the nasty question, do 'you' want me meddling with the core code that writes out packages ? I can easily make the existing examplewindow code do whats needed but changes will have to happen to that packaging code too ! I have not yet looked to see just how that will work.
Davo
Recent
