Get third party libraries via repo mirroring and DEPS rather than direct checkin to pdfium repo.

[GoogleCodeExporter]

PDFium, it turns out, has some upstream open-source dependencies (like 
libopenjpeg).  Currently, these are updated via a manual merge/checkin process. 
 Using the DEPS mechanism may be better.

Original issue reported on code.google.com by tsepez@chromium.org on 3 Oct 2014 at 6:08

[GoogleCodeExporter]

@tsepez, does this require libopenjpeg to be in src/third_party?

Original comment by bo...@foxitsoftware.com on 3 Oct 2014 at 6:10

[GoogleCodeExporter]

@tsepez, does this require libopenjpeg to be in src/third_party?

Original comment by bo...@foxitsoftware.com on 3 Oct 2014 at 6:10

[GoogleCodeExporter]

By src/third_party, do you mean chromium's top level src/ directory? ==> 
(answer NO).  Or do you mean the pdfium/third_party directory where the 
logging.h and template_util.h stuff lives? ==> (answer YES).

I believe that the DEPS mechanism could place it anywhere in the source tree, 
but it would match the convention if it lived in pdfium/third_party/libopenjpeg 
(and so forth).

Original comment by tsepez@chromium.org on 3 Oct 2014 at 6:19

[GoogleCodeExporter]

I see. In that way, seems we still have to manually merge the change from 
libopenjpeg to pdfium/third_party/libopenjpeg?

Original comment by bo...@foxitsoftware.com on 3 Oct 2014 at 6:22

[GoogleCodeExporter]

No.  There is a way to setup googlecode to mirror other repositories upstream 
(though I don't know the exact details - jam@?).  Once set up, doing an upgrade 
should simply involve changing one line in the DEPS file to specify the desired 
revision hash, and doing a gclient sync.

Original comment by tsepez@chromium.org on 3 Oct 2014 at 6:26

[GoogleCodeExporter]

Original comment by tsepez@chromium.org on 3 Oct 2014 at 6:31

[GoogleCodeExporter]

@jam - do you think that this approach is reasonable?  Or is it too small to 
bother with.  Thanks.

Original comment by tsepez@chromium.org on 3 Oct 2014 at 6:36

[GoogleCodeExporter]

@jam, any suggestions on this issue? Since openjpeg is updating quite 
frequently based on pdfium bugs. If we are going to resolve this issue, then I 
am not going to manually merge the code. Thanks!

Original comment by bo...@foxitsoftware.com on 6 Oct 2014 at 9:28

[GoogleCodeExporter]

@bo - things to consider:
1.  Do you ever need to modify the dependent source as part of your check-ins?  
If we are to go with DEPS, its helpful if you're happy with it byte-for-byte.
2.  Are you sub-setting the dependent repository?  If we go with DEPS, we may 
introduce a little bloat if you are only using a small portion of the code.
3.  Do you ever need to push patches before they are available up-stream?  This 
too is easier with checked in code.

Original comment by tsepez@chromium.org on 7 Oct 2014 at 6:04

[GoogleCodeExporter]

Original comment by tsepez@chromium.org on 7 Oct 2014 at 6:06

[GoogleCodeExporter]

@tsepez, for your questions:
1. I don't modify the dependent source. What we have in pdfium is the the same 
as in upstream openjpeg.
2. We are only using the jp2 module in it and only part of the jp2 module.
3. I don't really have to push patches before they are available up-stream, as 
long as openjpeg team responds to the issues timely, which seems to be the case 
now.

Still, I feel using DEPS is easier to capture their update.

Original comment by bo...@foxitsoftware.com on 7 Oct 2014 at 6:19

[GoogleCodeExporter]

@bo - thanks.  I agree.

Original comment by tsepez@chromium.org on 7 Oct 2014 at 6:30

[GoogleCodeExporter]

Update - I've moved most of the third party libraries out from under fxcodec 
and fxcrt to third_party/.  However, there is work to be done to restore these 
to their pristine condition (without breaking pdfium).  

Dauting because we don't know what tweaks FX may have made to these.  
Generally, if you're tweaking these, then you have a bug and need to find 
another approach and/or get it fixed upstream.

Original comment by tsepez@chromium.org on 19 Jun 2015 at 4:44