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 <[email protected]
> 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
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
