Building a JUCE module for fftw - how to deal with tons of library-sourcefiles?

General JUCE discussion
1

Hi,

I used fftw as a static precompiled library in non JUCE-related & platform specific projects before and I really like that library. So, while getting more and more familiar with JUCE, I’d love to build a JUCE module for fftw, including a nice C++ wrapper.

Following the idea of JUCE modules (if I got everything right), I thought it would be cool to be indepentend of precompiled library versions for each platform. From the fftw manual I got this information:

It should be relatively straightforward to compile FFTW even on non-Unix systems lacking the niceties of a configure script. Basically, you need to edit the config.h header (copy it from config.h.in) to #define the various options and compiler characteristics, and then compile all the ‘.c’ files in the relevant directories.

So basically my idea was, to generate multiple platform specific config.h files and #include all .c source files (some hundred - I wrote a script, scanning all source file folders to automatically build this file) in the master module .cpp file to compile the whole library. However, there are a lot of .c files in this library, containing the typedefs “P” and “S”, always referring to different kinds of structs. So doing it this simple leads to a lot “Typedef redefinition” errors.
My first thought was to exclude all files containing these typedefs from the master .cpp module file and #include them into additional .cpp module files. However, these are really lots of files, so I’d probably end up in having about 30-40 .cpp files in my modules root folder, which might somehow work for modules included with the projucer, but as the module format documentation says:

In some cases (e.g. if your module internally relies on 3rd-party code which can’t be
easily combined into a single compile-unit) then you may have more than one source file
here, but avoid this if possible, as it will add a burden for users who are manually
adding these files to their projects.

I’d really like to avoid this mess if possible.
Now my question is, if there are any clever workarounds in this Situation? How would you do this? Is there any nice C++ option I’m not aware of to somehow “undef” a typedef after each #include of a .c source file that typedefed P or S again?
Looking forward to your Ideas :wink:

2

When I’ve done this (e.g. with zlib, jpeglib, pnglib, etc) I’ve really just attacked it by brute force, including the C files and undeffing anything that seemed to be causing a compiler error! But no, I’m afraid there aren’t any compiler tricks I know about - certainly a pragma that did “push/pop the entire compiler state” would be very handy!

3

…oh, but re: typedefs, you can always wrap things in namespaces to avoid those collisions. It’s really just macros that are a bit of a nightmare.

4

Okay - if I get you right you’d recommend something like this?

namespace fftw_4_juce_source1 {
#include "fftw_source1.c"
}

namespace fftw_4_juce_source2 {
#include "fftw_source2.c"
}

...

Now to ensure that the functions from these source files are found, should I put

using namespace fftw_4_juce_source1;
using namespace fftw_4_juce_source2;
...

into my master module header file to be able to call the library functions without these auto-generated namespaces? I’m not sure how that should work for all function calls from within the single library source files that do not include my master module header file - or did I get you wrong at this point?

5

Yeah, that’d be a sensible approach, though I don’t think I ever needed to resort to differently named ones. The hackery you need really depends on the library…