Move fpdfsdk/include/formfiller to fpdfsdk/formfiller.

Move fpdfsdk/include/formfiller to fpdfsdk/formfiller.

This CL moves the .h files and renames the .cpp files to match.

R=tsepez@chromium.org

Committed: https://pdfium.googlesource.com/pdfium/+/edbb319d3143692befdbb0603089b7e265cf89aa

[dsinclair, 2016-03-17 19:05:56]

dsinclair@chromium.org changed reviewers:
+ tsepez@chromium.org

[dsinclair, 2016-03-17 19:05:57]

PTAL.

[Tom Sepez, 2016-03-17 20:01:53]

https://codereview.chromium.org/1809193002/diff/1/BUILD.gn
File BUILD.gn (right):

https://codereview.chromium.org/1809193002/diff/1/BUILD.gn#newcode777
BUILD.gn:777: "fpdfsdk/formfiller/cba_fontmap.cpp",
There's got to be at least one header in fpdfsdk/formfiller/include, otherwise
how do you call into this library?

[dsinclair, 2016-03-17 20:03:14]

On 2016/03/17 20:01:53, Tom Sepez wrote:
> https://codereview.chromium.org/1809193002/diff/1/BUILD.gn
> File BUILD.gn (right):
> 
> https://codereview.chromium.org/1809193002/diff/1/BUILD.gn#newcode777
> BUILD.gn:777: "fpdfsdk/formfiller/cba_fontmap.cpp",
> There's got to be at least one header in fpdfsdk/formfiller/include, otherwise
> how do you call into this library?


All usage is internal to fpdfsdk/. We don't need to DEPS anything to use
formfiller.

[Tom Sepez, 2016-03-18 16:29:47]

On 2016/03/17 20:03:14, dsinclair wrote:
> On 2016/03/17 20:01:53, Tom Sepez wrote:
> > https://codereview.chromium.org/1809193002/diff/1/BUILD.gn
> > File BUILD.gn (right):
> > 
> > https://codereview.chromium.org/1809193002/diff/1/BUILD.gn#newcode777
> > BUILD.gn:777: "fpdfsdk/formfiller/cba_fontmap.cpp",
> > There's got to be at least one header in fpdfsdk/formfiller/include,
otherwise
> > how do you call into this library?
> 
> 
> All usage is internal to fpdfsdk/. We don't need to DEPS anything to use
> formfiller.


What I'm asking is this:  If libformfiller.a was (somehow) obtained in binary
form only, where would its callers get a header file defining the entry points
they can call?  Is there any inclusion of fpdfsdk/formfiller/*.h from any other
directory? Or is it the case that all entry into this library is through public/
functions?

[dsinclair, 2016-03-18 23:16:06]

On 2016/03/18 16:29:47, Tom Sepez wrote:
> On 2016/03/17 20:03:14, dsinclair wrote:
> > On 2016/03/17 20:01:53, Tom Sepez wrote:
> > > https://codereview.chromium.org/1809193002/diff/1/BUILD.gn
> > > File BUILD.gn (right):
> > > 
> > > https://codereview.chromium.org/1809193002/diff/1/BUILD.gn#newcode777
> > > BUILD.gn:777: "fpdfsdk/formfiller/cba_fontmap.cpp",
> > > There's got to be at least one header in fpdfsdk/formfiller/include,
> otherwise
> > > how do you call into this library?
> > 
> > 
> > All usage is internal to fpdfsdk/. We don't need to DEPS anything to use
> > formfiller.
> 
> 
> What I'm asking is this:  If libformfiller.a was (somehow) obtained in binary
> form only, where would its callers get a header file defining the entry points
> they can call?  Is there any inclusion of fpdfsdk/formfiller/*.h from any
other
> directory? Or is it the case that all entry into this library is through
public/
> functions?


The formfiller code is called from three files:
 * fpdfsdk/fsdk_annothandler.cpp
 * fpdfsdk/fsdk_baseform.cpp
 * fpdfsdk/fsdk_mgr.cpp

In all cases they use CFFL_IFormFiller which will represent one of the other
types.

As far as I understood, we were only putting files into an include/ directory
when it crossed DEPS boundaries. Putting all of the files that match other
directories like fpdf_page/fpdf_parser would mean that pretty much every .h file
will be in include. I'd though we'd said we didn't want that?

[Tom Sepez, 2016-03-18 23:22:33]

Ok, LGTM for now.  I think the issue is that DEPS should also correspond to
include/ should corespond to the individual libraries in .gyp.  So maybe the
formfill library gets combined with the fpdfsdk one in the build system, and the
issue becomes resolved.  Looking at a library in the build system that doesn't
have any include/ headers should be a red flag.

[dsinclair, 2016-03-18 23:26:45]

On 2016/03/18 23:22:33, Tom Sepez wrote:
> Ok, LGTM for now.  I think the issue is that DEPS should also correspond to
> include/ should corespond to the individual libraries in .gyp.  So maybe the
> formfill library gets combined with the fpdfsdk one in the build system, and
the
> issue becomes resolved.  Looking at a library in the build system that doesn't
> have any include/ headers should be a red flag.

Ah, I see where you're coming from now.  I'm not sure how the .gyp libraries
compare to layout in the source tree. Maybe this is a case where the formfiller
target doesn't actually need to exist, or maybe it should be pulled out to a
higher level. I'll file a bug to look into this in the future.

[dsinclair, 2016-03-21 13:08:27]

Description was changed from

==========
Move fpdfsdk/include/formfiller to fpdfsdk/formfiller.

This CL moves the .h files and renames the .cpp files to match.
==========

to

==========
Move fpdfsdk/include/formfiller to fpdfsdk/formfiller.

This CL moves the .h files and renames the .cpp files to match.

R=tsepez@chromium.org

Committed:
https://pdfium.googlesource.com/pdfium/+/edbb319d3143692befdbb0603089b7e265cf...
==========

[dsinclair, 2016-03-21 13:08:28]

Committed patchset #2 (id:20001) manually as
edbb319d3143692befdbb0603089b7e265cf89aa (presubmit successful).