add abi-compliance-checker to travis script

[jjallaire]

see: http://manpages.ubuntu.com/manpages/natty/man1/abi-compliance-checker.1.html

Would give us more accurate notion of whether potential changes actually break the ABI (e.g. #260)

[eddelbuettel]

How do you envision doing this? Build the new shared library but also include the Ubuntu package (which I happen to have turned just recently for regular builds via this old PPA of mine) and compare those two?

[jjallaire]

I was thinking we'd have to install the current CRAN version into a
separate library and then compare, but the Ubuntu package seems like an
even better idea.

On Fri, Feb 20, 2015 at 11:07 AM, Dirk Eddelbuettel <
notifications@github.com> wrote:

How do you envision doing this? Build the new shared library but also
include the Ubuntu package (which I happen to have turned just recently for
regular builds via this old PPA of mine
https://launchpad.net/%7Eedd/+archive/ubuntu/misc/+packages) and
compare theoe two?

—
Reply to this email directly or view it on GitHub
#261 (comment).

[eddelbuettel]

Right. We get it build "independently" by Ubuntu/Canonical/Launchpad but from the same source and the same (bloody dated) 12.04 distro release.

[jjallaire]

It looks like it's also possible to create an ABI dump of an existing
library and then compare against the dump. In that case we could create the
ABI dump and check it into the Rcpp tree and then use that for the
comparison.

I'll spend some more time looking into this early next week.

On Fri, Feb 20, 2015 at 12:31 PM, Dirk Eddelbuettel <
notifications@github.com> wrote:

Right. We get it build "independently" by Ubuntu/Canonical/Launchpad but
from the same source and the same (bloody dated) 12.04 distro release.

—
Reply to this email directly or view it on GitHub
#261 (comment).

[jjallaire]

Spent a couple hours playing with this today. The complexity of the Rcpp codebase makes getting a reliable (no false positives, etc.) version of the abi-compliance-checker working a substantial effort. For now I'd say let's keep the library loading test you already have.

[eddelbuettel]

Thanks for doing all that work. I was also thinking that maybe ... we just make that a local script?

Do you feel like jotting a few bullet points together, maybe for the RcppCore/Rcpp wiki at GH?

[jjallaire]

Even the local script is going to be hard to get right. The tool has a hard
time parsing the Rcpp headers (because some of them are "partial" i.e. have
implicit dependencies that are met only when other headers are included
before them). Rcpp also exports a bunch of symbols using R's GetCCallable
mechanism and I don't think the tool can check that at all. We can probably
can more confidence from enhancing the approach you already have by running
more Rcpp code (i.e. more tests) over the "old" library.

On Sat, Feb 21, 2015 at 11:43 AM, Dirk Eddelbuettel <
notifications@github.com> wrote:

Thanks for doing all that work. I was also thinking that maybe ... we just
make that a local script?

Do you feel like jotting a few bullet points together, maybe for the
RcppCore/Rcpp wiki at GH?

—
Reply to this email directly or view it on GitHub
#261 (comment).

[eddelbuettel]

Gotcha. The "hybrid" nature of being C++ but called from R makes for some nice non-standard corners.

Expanding the test script should work.