On 16.04.2012 17:33, Ariel Constenla-Haile wrote:
On Mon, Apr 16, 2012 at 01:37:45PM +0800, Andre Fischer wrote:
As for the downloaded extension.  I see this problem as an
inconvenience at best.  For a new extension you have to update the
main/extensions.lst file anyway, so that the new MD5 sum is used.
If you do a clean build then everything is fine.

That's not the case, unless by clean build you mean removing the whole
source tree and checking the source again.

That is indeed what I meant.

Reading
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots#AOO3.4UnofficialDeveloperSnapshots-buildflags
it does not seem the case with the MacOS script, and I do (only) clean
the source tree:

cd trunk
rm -rf */*/unxlngx6.pro
rm -rf */*/unxlngi6.pro
rm -rf main/solver/*/unxlngx6.pro
rm -rf main/solver/*/unxlngi6.pro

I prefer

rm -rf main/solver
cd instsetoo_native
build --prepare --from solenv

but that would not solve the problem either.


That's what I understand as a clean build.
Of course I can remove the whole source tree and check it again, but you
can not expect everyone building AOO to do so.

No, I guess not. I admit that the current behavior has to be improved. I will do that after the 3.4 release.


The described problem occurs only if one tries to save time by
reusing previously downloaded extensions.

The time is saved by not checking out the whole source tree, not the
previously downloaded extensions, they are downloaded to a folder that
contains source.

You save time by

- not checking out the source tree
- not downloading source tar balls
- not downloading dictionaries/extensions



As I said above, I will improve this after the release.
Something like:

    Download extension if
    - it is missing from ext_sources/
    - the extension in ext_sources/ has a different MD5 checksum from
      the one in main/extensions.lst

Other, better ideas?

Reply via email to