>...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. >Can you use this? >http://www.cs.berkeley.edu/~necula/cil/merger.html 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!! _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
