good chemistry is complicated,
and a little bit messy -LW
pull a CPAN+ conf itemby Intrepid (Deacon)
|on Apr 05, 2010 at 17:17 UTC||Need Help??|
Another incomprehensible node from me
The trouble with using a nice tool like CPANPLUS for installing Perl software from CPAN is that sometimes you can't ;-)
Relying on whatever one did when setting up CPANPLUS the first time, one easily forgets what the conf settings were and just lets the cpanp command do its thing. That's just what it is for, and that's great.
But then one stumbles into a project like Image Magick (imagemagick) with the PerlMagick component, which is built “in-tree” when compiling the C/C++ main portion of the project. Building from source for experimentation with a pull of the latest devel branch, say, or for any other of many good reasons that one could have. What was once a convenience—CPANPLUS taking care of 'remembering' your installFOO dirs, forexample—now becomes an obstacle. You can fool around for many minutes figuring out what on-disk location(s) CPANPLUS stores its configuration in, or you can use this odd little technique we like to call programming to aquire this information with far less irritation and effort.
All that it takes is addition of something like this snippet to a Makefile (it will be a generated Makefile in cases where the the GNU Autotools or similar are employed), before running the make command in the cli/console.
Disclaimer: use at your own risk. No guarantee of efficacy or protection from hair loss is made or implied.
The following snippet is also an example of one way (Intrepid's way) of “embedding”small Perl programs in a Makefile. It is not the only possible way. And it relies on this Makefile being a GNU makefile, that is, the make tool being used to interpret and execute the Makefile must be GNU make. See further notes below.For those who were not paying attention: This is make "code", not Perl except for the part in between the define and endef.
This works nicely because the GNU-make define FOOBAR directive used above creates a quantum of data that isn't evaluated as a Make directive / statement at the time of declaration. That is, the sigils ($) in the Perl code are not “dereferenced” or “evaluated” as make variables at the time that make reads in the statement, as it makes a parsing pass through the Makefile.
By later using the $(value <...>) function to protect the sigil-strings (Perl scalars variables) from premature molestation by make (so that they are passed through unaltered to the system command interpreter (sh) and thus to perl), we manage to take our precious bits of enlightened Perl wisdom like the perl code above, and get it delivered to perl for execution.
The use of little files written to disk in the build tree, by make, in the process of acquiring this data for build configuration, is a necessary evil, it seems. RFF! (Request For Feedback).
The Perl code is shown in isolation here:
Whether you found this edifying or irritating, next time you hear that someone cannot figure out how to extract some conf settings from the inner sanctum of a utility like CPANPLUS, remember to advise them (please don't “advice” them) that CPANPLUS comes with documentation that describes an API for doing exactly that.
[Intrepid|Soren Andersen / “somian” / “perlspinr”]