> 1. The `rules.mk' of the `svg' module compiles the port files. That
> should only be compiled only if a default SVG port is needed,
> otherwise not. So, my question was how do I access this
> information (whether `yes'/`auto' was selected or `no-default')
> in my `rules.mk'. The solution I am using temporarily is, I
> create the placeholder for a new variable in `unix-cc.in' called
> `COMPILE_SVG_PORT', this placeholder gets filled by the script
> `configure.raw' and I can access this variable from `rules.mk'.
> Let me know if there's a better solution here.
This looks like the right solution. There should be other, similar
use-cases already in the code.
> 2. A concern I have is that at the moment, the `includes' for
> `librsvg' (my temporary default for experimentation) gets
> appended to the variable `CFLAGS' in `configure.raw', the same is
> the case for `harfbuzz' and `libpng' as well. However, in the
> case of an SVG library, these `includes' are only needed in the
> compilation of the default port, and nowhere else. Would it be a
> good idea to create a separate variable called `LIBRSVG_CFLAGS'
> in `unix-cc.in'? This way, we can only use the flags where they
> are actually required. Or would that be an overkill and isn't
> really important?
Theoretically, this is a good idea, since it avoids potential name
clashes and makes compilation faster. On the other hand, I think it
is overkill since virtually all Unix programs accumulate include file
directories in the way you are describing.
FreeType is a small library with a very limited set of necessary
libraries. I think we thus don't need a better solution.
> 3. I want the `svg' module to not get compiled if `--with-svg' was
> set to `no'. I could use a similar trick as in (1) but
> `modules.cfg' gets included far before `unix-cc.mk' is.
Simply protect the whole code in the SVG module file(s) with
#ifdef FT_CONFIG_OPTION_SVG
...
#endif
Compare this to, say, the `bzip2' module code.
Werner
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
