Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I recently stumbled upon this in a project I’m working on. In package A, there is a required configuration option --package-B-makefile-location from which A‘s makefile borrows variable values.
Is this a common design pattern which has merit? It seems to me that B‘s package source is as important as its binary for compiling A. Might there be reasons I wouldn’t want to tamper with it?
Thanks,
Andrew
It is far from unheard of for one package to need other packages pre-installed, and you have to specify those locations.
For example, building GCC (4.5.2), you need to specify the locations of the GMP, MPFR and MPC libraries if they won’t be found by default.
Complex systems which are extensible – Perl, Apache, Tcl/Tk, PHP – provide configuration data to their users in various ways (Config.pm for Perl, apxs for Apache, etc), but that configuration data is crucial to dependent modules.
My suspicion is that your Package A needs some of the configuration data related to Package B, but there isn’t a fully-fledged system for providing it. As a workaround, Package A needs to see the configuration data encapsulated in the makefile.
It is not common to need the makefile; it is not uncommon to need some information about other packages.