On Oct 19, 2011, at 3:29 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-18 22:16, katja wrote:
On Tue, Oct 18, 2011 at 8:33 PM, Hans-Christoph Steiner <hans@at.or.at
wrote:
Another idea for handling this is to use the ./configure --enable-double-precision flag, but have it generate a config.h, which is included by m_pd.h. That should solve this issue, since config.h would be auto-generated based on the flag, but all externals would use m_pd.h, which reads the PD_FLOAT_PRECISION value from config.h
Ah yes that sounds like a good solution. But what if a lib is built
i don't think so, mainly because i encountered lots of problems with this in the past. config.h is BAD, because it is a very commonly named file.
if we have pd/m_pd.h pd/config.h myexternal/myexternal.c myexternal/config.h
then i think the inclusion of "config.h" can be ambiguous; your compiler might happen to know which config.h to include; it might as well not know; i'd rather not chance the odd case where the wrong config.h is included.
even if the inclusion gets right, there are pitfalls if you use "config.h" as the general output of configure (which i assume, since you chose this naming), where you define things like which header is present (something like HAVE_ALSA_ASOUNDLIB_H): the header might have well existed when pd was built, but there is absolutely no guarantee that it is there when the external is build. however, the external might include code that could use that very header, and the build will fail spectacularily.
so, i would definitely separate the files that hold information on how to build Pd (either by simply adding flags to the DEFS or by use the traditional config.h) from the files that hold information on how to build _for_ pd (e.g. externals), aka the public API.
i fail to see the drawbacks of my suggestion [1] to use a file m_types.h that contains solely the information about how to deal with types, and this could be (partly) generated from information for configure.
mfgsdr IOhannes
If pd/src/m_pd.h is the only thing that loads pd/src/config.h and m_pd.h does #include "config.h", this is not a problem.
"GCC looks for headers requested with #include "file" first in the directory containing the current file". http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
config.h is the standard name for the header generated by ./ configure. I think they probably have thought of the above issues.
.hc
----------------------------------------------------------------------------
Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs