search

speedyzhou / pdfium

Automatically exported from code.google.com/p/pdfium
0 stars 0 forks source link

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

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
@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 commented 9 years ago 
@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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago

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

GoogleCodeExporter commented 9 years ago 
@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 commented 9 years ago 
@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 commented 9 years ago 
@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 commented 9 years ago

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

GoogleCodeExporter commented 9 years ago 
@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 commented 9 years ago 
@bo - thanks.  I agree.

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