Seeking advice on packaging PDFium

[Ted Han]

Hey Folks.

I work on a project called DocumentCloud.  We open source most of our components, and part of our tools consists of a PDF processing pipeline.  Part of that pipeline is a PDF -> raster image renderer, and up until very recently we'd been using graphicsmagick+ghostscript to accomplish this (https://github.com/documentcloud/docsplit/blob/master/lib/docsplit/image_extractor.rb for the curious).

But we've shifted away from gm+gs by writing a Ruby C/C++ extension that wraps PDFium which we would like to release for others to use too.

Our primary concern before we are able to release our rubygem is the ease of installing pdfium as a library on OSX & Linux (primarily ubuntu), and we were wondering whether any maintainers and/or listers had any suggestions or advice on the topic.

We've written a homebrew formula that's HEAD only (which pulls from the git repo & then builds the lib as one would expect using gyp & ninja) and some scripts to build a .deb and we'd like to figure out a way to keep things updated in a reliable/consistent fashion.

We'd love to be able to follow v8's path (see https://github.com/Homebrew/homebrew/blob/master/Library/Formula/v8.rb ), but unfortunately the PDFium repo differs from v8s in that v8 uses git tags to identify the version being shipped w/ particular Chrom(e|ium) versions.  If anyone knows another way to track that correspondence we'd be really interested to hear it.

Anyway, thanks for reading.  Suggestions very welcome!

-Ted Han

[John Abd-El-Malek]

Hey Ted, nice to hear of more users of PDFium :)

I'm not sure exactly what you're looking for compared to V8. Are you looking for us to annotate PDFium branches with which Chrome release they use? Why do you care about which version of Chrome the PDFium source you're using goes into?

--
You received this message because you are subscribed to the Google Groups "pdfium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdfium+un...@googlegroups.com.
To post to this group, send email to pdf...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pdfium/32d78add-25ba-4947-82e8-c5c943358a8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ted Han]

Hey John!

Definitely.  So the core issue for us is just knowing where good checkpoints are to hook releases to for packaging purposes.  The ergonomics from our perspective revolve around the way that folks tend to use package managers.  When do we expect people to update their packages, what's a good interval over which we push out new versions of the package, what does the variation between packages look like and so on.

Although i don't think its representative of a frequent occurance, the rearrangement of PDFium's dependencies in the `third_party` directory recently is one example of where we need to make sure that our packaging keeps up to date with the layout of files (and where headers live) in the repo.  Because of that, asking users to just pull from HEAD in an automated fashion is a potential source of build errors for things like our rubygem.

On our end we could just pick a monthly or weekly interval to select to whatever commit happens to be on HEAD to create new packages, but it would be helpful/aesthetically nice to be able to tie to something that'll match up with somebody's existing release cycle.

So, yep, annotating with Chrome versions would give us something that we could run with.  We're not inherently wedded to Chrome's versioning specifically, we'd just like some consistent reference points to refer to.

Best,

-Ted

[John Abd-El-Malek]

On Tue, Feb 24, 2015 at 8:03 AM, Ted Han <t...@knowtheory.net> wrote:

Hey John!

Definitely.  So the core issue for us is just knowing where good checkpoints are to hook releases to for packaging purposes.

Chromium, and subprojects like PDFium, have a mantra of trunk is always stable. So I wouldn't worry about trying to pick specific branches or revisions.

 

 The ergonomics from our perspective revolve around the way that folks tend to use package managers.  When do we expect people to update their packages, what's a good interval over which we push out new versions of the package, what does the variation between packages look like and so on.

Although i don't think its representative of a frequent occurance, the rearrangement of PDFium's dependencies in the `third_party` directory recently is one example of where we need to make sure that our packaging keeps up to date with the layout of files (and where headers live) in the repo.  Because of that, asking users to just pull from HEAD in an automated fashion is a potential source of build errors for things like our rubygem.

On our end we could just pick a monthly or weekly interval to select to whatever commit happens to be on HEAD to create new packages,

Yep I would go with that approach.

 

but it would be helpful/aesthetically nice to be able to tie to something that'll match up with somebody's existing release cycle.

Apart from Chrome's release schedule not announced ahead of time, this isn't going to buy you much.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/pdfium/c4b9deb9-014b-412a-8984-125c18cb371b%40googlegroups.com.

[Ted Han]

Thanks for the advice.  I guess we'll just periodically create updated packages and release them, just starting from 1 and counting up towards infinity.