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

[Hans-Christoph Steiner]

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