R devel - Sep 2016 - forgive possible repost: alternate bzip2 library

Hi,

I am resubmitting a question, mainly because I suspect I may have
inadvertently cancelled it, while it was awaiting moderator approval.

It's about manually compiling R-3.3.1 and using, not the standard
system's
(ver 1.0.5), but an alternate a bzip2 (v1.0.6) which is located in a
non-standard location.

I usually lean on pkg-config to deal with issues like this. I've create an
appropriate bzip2.pc file for bzip2 for this purpose.

I've been focusing on the configure script, which at 50K lines is quite
hefty and my initial question was whether the R compile configure script
used pkg-config for locating headers and libraries.

My feeling now is that the answer is "sometimes". In locating
cairographics, it says it does, but for bzip2 I think it uses autoconf's
dubious magic. Don't know if anybody can confirm this.

I could modify the configure so that it looks for bzip2 via pkg-config but
manual modification of this script is probably not proper practice, as well
as being very time consuming.

Any guidance appreaicted. Many thanks.

	[[alternative HTML version deleted]]

On 9 September 2016 at 12:21, Ram?n Fallon wrote:
| I am resubmitting a question, mainly because I suspect I may have
| inadvertently cancelled it, while it was awaiting moderator approval.
| 
| It's about manually compiling R-3.3.1 and using, not the standard
system's
| (ver 1.0.5), but an alternate a bzip2 (v1.0.6) which is located in a
| non-standard location.
| 
| I usually lean on pkg-config to deal with issues like this. I've create an
| appropriate bzip2.pc file for bzip2 for this purpose.
| 
| I've been focusing on the configure script, which at 50K lines is quite
| hefty and my initial question was whether the R compile configure script
| used pkg-config for locating headers and libraries.

You want configure.ac, the source, not configure, the 'compiled' output.
 
| My feeling now is that the answer is "sometimes". In locating
| cairographics, it says it does, but for bzip2 I think it uses autoconf's
| dubious magic. Don't know if anybody can confirm this.
| 
| I could modify the configure so that it looks for bzip2 via pkg-config but
| manual modification of this script is probably not proper practice, as well
| as being very time consuming.

As a (local) one-off, you could. You could continue to locally patch configure.

In general, pkg-config is good (and I just filed a request for another
library to support it).  Maybe here, you could work on a patch to
configure.ac to _first_ use pkg-config for bzip2, and, if no result was
found, fall back on the current behaviour.  It's tricky.  R has a very
mature
and very well tested build system, so for all changes you want to make
/really/ sure you are not compromising any existing behaviour.

Dirk


-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

Dirk, thanks for your reply ... yes configure.ac, definitely. OK, mature
build system ... that's a warning indeed, though of course some dependency
libs already are treated like this, bitmaps/jpg for example: configure.ac

## Bitmap headers and libraries.
if test -n "${PKGCONF}"; then
R_BITMAPS2
else
R_BITMAPS
fi

(although the test here is existence of pkg-config, not if it finds
libraries). R_BITMAPS must be a set of macros of some sort. Will go out
hunting them now, unless anybody mentions where/how they live.

Cheers!


On Fri, Sep 9, 2016 at 3:07 PM, Dirk Eddelbuettel <edd at debian.org>
wrote:
>
> On 9 September 2016 at 12:21, Ram?n Fallon wrote:
> | I am resubmitting a question, mainly because I suspect I may have
> | inadvertently cancelled it, while it was awaiting moderator approval.
> |
> | It's about manually compiling R-3.3.1 and using, not the standard
> system's
> | (ver 1.0.5), but an alternate a bzip2 (v1.0.6) which is located in a
> | non-standard location.
> |
> | I usually lean on pkg-config to deal with issues like this. I've
create
> an
> | appropriate bzip2.pc file for bzip2 for this purpose.
> |
> | I've been focusing on the configure script, which at 50K lines is
quite
> | hefty and my initial question was whether the R compile configure script
> | used pkg-config for locating headers and libraries.
>
> You want configure.ac, the source, not configure, the 'compiled'
output.
>
> | My feeling now is that the answer is "sometimes". In locating
> | cairographics, it says it does, but for bzip2 I think it uses
autoconf's
> | dubious magic. Don't know if anybody can confirm this.
> |
> | I could modify the configure so that it looks for bzip2 via pkg-config
> but
> | manual modification of this script is probably not proper practice, as
> well
> | as being very time consuming.
>
> As a (local) one-off, you could. You could continue to locally patch
> configure.
>
> In general, pkg-config is good (and I just filed a request for another
> library to support it).  Maybe here, you could work on a patch to
> configure.ac to _first_ use pkg-config for bzip2, and, if no result was
> found, fall back on the current behaviour.  It's tricky.  R has a very
> mature
> and very well tested build system, so for all changes you want to make
> /really/ sure you are not compromising any existing behaviour.
>
> Dirk
>
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>
	[[alternative HTML version deleted]]