>...I add twenty-five FreeType C files directly to the project or makefile...
>...It is tedious since they are in a bunch of different folders that also
>...contain other C files that should NOT be added.
I have noticed this as well. The only way to figure out which .c are actually
needed is to consult the project file or Makefile.
>...there are several macros that would not work if all sources are concatenated.
>...An example is GET_PIC() macro defined by src/xxx/yyypic.h. and src/xxx/ttpic.h
Isn't this easily fixed by renaming one of the #define and changing the appropriate
source files?
>When I found them, I could not decide which is appropriate direction quickly;
>giving some prefix/suffix to separate them to different namespaces, or the
>insertions of "#undef GET_PIC" macros.
What's wrong with #define GET_PIC and #define GET_PIC2 (for example)? At
least this way the identifiers are unique and you can distinguish them in a search.
This is a nifty program but it doesn't produce an amalgamation. In order for the
resulting amalgamation to retain all of the original functionality, the C preprocessor
should NOT be run on the sources. Directives need to remain intact. Well, except
for certain #include lines (which cause the file to get inserted on the first occurrence).
>Such an approach would make the output more difficult to edit directly
>though, so it would then really only be meant to be regenerated when
>changes are made to the original source.
An amalgamation is never edited directly. It is always recreated from the
original sources.
>> 1) Some FreeType #include statements use angle brackets instead of
>> double quotes. e.g. #include <ft2build.h> Why?
>
>This is to control inclusion with the -I command line flag of the
>compiler. Think of build_dir != src_dir (which is very common on Unix
>boxes).
I understand the angle brackets now. It is because there are several
versions of ft2build.h. If we roll them all together into a single file with
appropriate preprocessor directives to decode the platform then the
angle brackets would no longer be necessary, since there would only
be one file.
>> 2) Some FreeType #include statements use macros, like "#include
>> FT_GLYPH_H". This complicates automated tools.
>
>I neither have time nor energy to change that. It's there since ten
>years, and it works essentially everywhere. Note that there are other
>packages which do similar things, for example `boost'.
Sure, but it gets in the way of an amalgamation. It can be worked around
though. However, what is the purpose? Is there ever a situation where
FT_GLYPH_H is defined to something other than what exists in the
header file?
>> 3) A new ftconfig.h should be created that has a preamble for
>> decoding the platform, [...]
>
>How shall this work? There are dozens of platforms, and you want to
>hard-code them all in a configuration header file?
Yes, that is the hope. This is the approach taken by boost.
>Let me ask it differently: What platforms are you going to support? A
>generic solution needs configuration done by an external tool
>(e.g. autoconf), but this somehow contradicts your idea of simply
>having everything in a large file.[1]
The amalgamation should work with all platforms that FreeType currently
supports, of course! Requiring autoconf also contradicts the purpose of
this. It should be possible to just "drop in" the amalgamation, to an existing
project, without running any separate tools. This way, when someone
publishes an application that uses the FreeType amalgamation, anyone
who wants to build it can just pick up the sources, open the project,
and press the "build button" (figuratively) - no separate tools, dependencies,
or configuration is needed.
>Given the many problems, I suggest a step-by-step approach, and I hope
>that you can assist, test, and develop.
Yes I agree. It's good to know about GET_PIC, that would trip up the
amalgamation. But it is easily fixed. The issue with the #include lines is
also fixable, for example:
amalgamator.exe -d FT_GLYPH_H=src/ftglyph.h ...
It could be a requirement of the amalgamation tool that macros used in
#include lines need to be defined via command line arguments.
>FreeType already supports flat-directory compilation (see docs/INSTALL.ANY),
>maybe this is a good starting point.
Well nice suggestion but this doesn't get us much. I prefer a requirement
of passing -l flags to the amalgamation tool to inform it of all the directories
to search for includes, because this way someone who wants to produce
an amalgamation does not have to re-shuffle the FreeType source tree after
they check it out.
>Note that David Turner developed the current macro inclusion scheme
>while working on a *Windows* box more than ten years ago, so it is not
>the result of sick Unix programmers :-)
My target audience...well lets just say that anything I develop needs to be
largely "idiot proof." Very often, people who download my code are
experiencing computer programming for the first time. They are musicians
or artists who want to try their hand at building an audio plugin with a
cool looking gui.
That one of the most active forums for audio plugin development discussion
has a thread titled "README - For non-programmers with great ideas" should
speak for itself.
The thread is here, for reference:
http://www.kvraudio.com/forum/viewtopic.php?t=194452&sid=056099e4691ee2b7324ccecafb6f60c4
>There were good reasons for it which you might look up in the archives.
How do I look this up?
If anyone is interested in compiling and running my DSP Filters demo on Linux
(or suitably compatible environment) these commands should work to build it:
unzip DSPFiltersComplete_0_9_72.zip
cd shared
g++ -o dspfiltersdemo $(find DSPFiltersDemo DSPFilters -name \*.cpp) JuceAmalgam/JuceLibraryCode*.
cpp -I JuceAmalgam -I DSPFiltersDemo/source/ -I DSPFilters/include/ $(pkg-config --cflags --libs freetype2 alsa) -ldl -lpthread -lrt -lX11 -lGL -lGLU -lXinerama -lXext
You can get the sources here:
http://code.google.com/p/dspfilterscpp/
As you can see, the amalgamation I used to bring in Juce is quite convenient.
No autoconf or anything is needed to build DSP Filters Demo and it should
work on most platforms that have the required support (ALSA, X11, couple
of others).
I want to be able to include and distribute FreeType the same way.
Thanks for all the feedback!!