[PD-dev] pd-double: how to selectively build external libs for development?

[IOhannes m zmoelnig]

-----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 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



[1] http://lists.puredata.info/pipermail/pd-dev/2011-10/017415.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6efFAACgkQkX2Xpv6ydvQiqwCeKSd9LaJKgBdI9YI+3+EwRVhE
K8UAnAmhdYW57L/TgrJJqBB5iCBS0COV
=9ENm
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20111019/91c6ddad/attachment-0001.bin>