Re: [patch] Simplify ftconfig.h
>> However, I've already invested a lot of time in writing ChangeLog
>> entries...
>
> Would you consider dropping the ChangeLog entries.
Basically, I don't object to that. However, experience has shown that
people tend to write very sloppy git commit messages in general. The
ChangeLog format enforces you to describe changes in a standardized
way that I consider very helpful.
> It is far simpler to rely on the git history for this, and just
> enforcing that committer provide meaningful commit messages should
> be enough?
If we can do what Emacs does – namely git commit messages in ChangeLog
style – I'm all for dropping direct ChangeLog entries.
> Also, whenever you reformat some of the patches that are sent to
> you, the original author has to resolve the conflicts manually, or
> drop its own branch, which is not always practical (e.g. when there
> are other work-in-progress commits/branches on top of the one that
> was originally submitted).
This is admittedly a problem.
> Would you consider using clang-format to automate the formatting
> task? I think we can get pretty close to the FreeType formatting
> standard with a Clang style sheet. It won't be 100% the same, but
> close enough to avoid repetitive work.
If you can manage to write that, please do! Automatic formatting has
definitely benefits. Honestly, I suggest that we get completely rid
of the special FreeType formatting. For consistency I'm enforcing it
on all pieces of code, but virtually all contributors have
difficulties to follow the (unwritten) rules. Something like
int main(int argc,
char **argv)
{
FT_Error error;
FT_Library library;
FT_Face face;
int i;
error = FT_Init_FreeType();
if (error)
{
foobar();
die("FT_Init_FreeType failed");
}
if (argc != 2)
die("no font file argument given");
...
looks nice IMHO – and is quite standard, AFAICS. Of course,
vertical alignment like
FT_Error error;
FT_Library library;
FT_Faceface;
inti;
is quite nice, too, but I doubt that it can be really handled
automatically.
Whatever you come up with, please check whether our API documentation
can be built correctly. Additionally, such a change should be
introduced right after a release.
> here's another patch that tries to fix this. Sorry about that.
> Also Ben Wagner noticed me that some third-party code is using
> FT_UNUSED(), so I've moved it back to public-macros.h to avoid
> breaking this.
Thanks, applied (with minor additions).
Werner
Re: [patch] Simplify ftconfig.h
Would you consider dropping the ChangeLog entries. It is far simpler to rely on the git history for this, and just enforcing that commiter provide meaningful commit message should be enough? Yes please. Alternatively, there are tools like https://pypi.org/project/towncrier/. > Would you consider using clang-format to automate the formatting task? I think we can get pretty close to the FreeType formatting standard with a Clang style sheet. It won't be 100% the same, but close enough to avoid repetitive work. YES YES YES. It is _so_ nice to just hit a format hotkey. It's become so automatic for me that I rarely think about formatting anymore.
Re: [patch] Simplify ftconfig.h
Le lun. 6 juil. 2020 à 11:58, Werner LEMBERG a écrit : > > > Werner, please don't commit something if you think there are still > > problems in it, that's what code reviews are, > > Normally, I do that. However, I've already invested a lot of time in > writing ChangeLog entries... > > Would you consider dropping the ChangeLog entries. It is far simpler to rely on the git history for this, and just enforcing that commiter provide meaningful commit message should be enough? Also, whenever you reformat some of the patches that are sent to you, the original author has to resolve the conflicts manually, or drop its own branch, which is not always practical (e.g. when there are other work-in-progress commits/branches on top of the one that was originally submitted). Would you consider using clang-format to automate the formatting task? I think we can get pretty close to the FreeType formatting standard with a Clang style sheet. It won't be 100% the same, but close enough to avoid repetitive work. > See attached patch for a fix. > > Applied, thanks. Note, however, that there are still issues with > `make multi CC=c++` (I'm using g++ 7.5.0): > > Yes, here's another patch that tries to fix this. Sorry about that. Also Ben Wagner noticed me that some third-party code is using FT_UNUSED(), so I've moved it back to public-macros.h to avoid breaking this. > c++ -ansi -pedantic \ > -Ifreetype2.compiled [...] \ > freetype2/src/base/ftsystem.c > In file included from freetype2/include/freetype/config/ftconfig.h:45:0, >from freetype2/src/base/ftsystem.c:29: > freetype2/include/freetype/config/public-macros.h:83:61: error: > expected unqualified-id before string constant >#define FT_EXPORT( x ) FT_PUBLIC_FUNCTION_ATTRIBUTE extern "C" x >^ > freetype2/include/freetype/fterrors.h:281:3: note: > in expansion of macro ‘FT_EXPORT’ > FT_EXPORT( const char* ) > ^ > > > Sorry about that. We need a better way to automatically check our > > builds. [...] I'll work on a proper rebuild-check script first > > though... > > I don't worry about that right now, and please don't invest too much > time here. This is something after a switch to a new build system > IMHO. > > > Werner > From 0cfacffe05ae6eeffe2df0d0663fa4666a8b6afc Mon Sep 17 00:00:00 2001 From: David Turner Date: Mon, 6 Jul 2020 10:56:36 +0200 Subject: [build] Fix multi and C++ builds. The following builds were failing due to previous changes: make multi make multi CC="c++" make CC="c++" This patch fixes the issues, which were missing includes to get the right macro definitions in multi-build mode. Also, FT_UNUSED() is actually used by third-party code, so move it back to to avoid breaking it. --- include/freetype/config/public-macros.h | 16 +--- include/freetype/internal/compiler-macros.h | 19 --- src/cache/ftccback.h| 2 ++ src/lzw/ftzopen.h | 3 +++ 4 files changed, 22 insertions(+), 18 deletions(-) diff --git a/include/freetype/config/public-macros.h b/include/freetype/config/public-macros.h index b1fa0f2b3..5cc3236ed 100644 --- a/include/freetype/config/public-macros.h +++ b/include/freetype/config/public-macros.h @@ -78,13 +78,23 @@ FT_BEGIN_HEADER * * FT_EXPORT( FT_Bool ) FT_Object_Method( FT_Object obj, ... ); * + * NOTE: This requires that all FT_EXPORT() uses are inside FT_BEGIN_HEADER .. + * FT_END_HEADER blocks. This guarantees that the functions are exported with + * C linkage, even when the header is included by a C++ source file. */ -#ifdef __cplusplus -#define FT_EXPORT( x ) FT_PUBLIC_FUNCTION_ATTRIBUTE extern "C" x -#else #define FT_EXPORT( x ) FT_PUBLIC_FUNCTION_ATTRIBUTE extern x + + /* `FT_UNUSED` indicates that a given parameter is not used -- */ + /* this is only used to get rid of unpleasant compiler warnings. */ + /* */ + /* Technically, this was not meant to be part of the public API, */ + /* but some third-party code depends on it. */ + /* */ +#ifndef FT_UNUSED +#define FT_UNUSED( arg ) ( (arg) = (arg) ) #endif + FT_END_HEADER #endif /* FREETYPE_CONFIG_PUBLIC_MACROS_H_ */ diff --git a/include/freetype/internal/compiler-macros.h b/include/freetype/internal/compiler-macros.h index 1f432bca5..b62c0777b 100644 --- a/include/freetype/internal/compiler-macros.h +++ b/include/freetype/internal/compiler-macros.h @@ -27,12 +27,6 @@ FT_BEGIN_HEADER # if defined( _COMPILER_VERSION ) && ( _COMPILER_VERSION >= 730 ) #pragma set woff 3505 # endif -#endif - - /* `FT_UNUSED` indicates that a given parameter is not used -- */ - /* this is only used to get rid of unpleasant compiler warnings. */ -#ifndef FT_UNUSED -#define
Re: Logging Library-GSOC
>> What do you mean with 'toggle'? > > In one of the previous mail, you mentioned that you wanted to print > FT_COMPONENTS along with actual log message only when there is some > string present in the FT2_DEBUG env variable. Therefore, I wanted > to ask about what exactly do you have in your mind about controlling > this behaviour, so that I could try to implement it... Thanks. For simplicity, let's assume that the addition of an argument `-v` to `FT2_DEBUG` activates the output of the `FT_COMPONENTS` strings in square brackets. Example: FT2_DEBUG="any:7 -v" Werner
Re: Logging Library-GSOC
*> I thought of> [] ...> where is the value given
in the `FT_COMPONENT` macro,> padded with spaces to ensure a uniform
width. Example:> [cffdriver] ...> [psconv ] ...> [sfobjs ] ...>
However, this should be freely adjustable – thus my request to make> `{`
and `}` configurable in the 'dlg' library.*
Ok
*> What do you mean with 'toggle'?*
In one of the previous mail, you mentioned that you wanted to print
FT_COMPONENTS along with
actual log message only when there is some string present in the FT2_DEBUG
env variable.
Therefore, I wanted to ask about what exactly do you have in your mind
about controlling this behaviour, so that I
could try to implement it...
On Mon, Jul 6, 2020 at 6:31 PM Werner LEMBERG wrote:
>
> >> Oh yes, you can! Either you modify the source code of 'dlg' within
> >> FreeType, or – which is better IMHO – you submit a feature request
> >> or patch to the 'dlg' maintainers that allows control of the '{'
> >> and '}' characters for marking tags. I see no reason why this must
> >> be hard-coded.
> >
> > Ok, I will talk to the dlg's maintainer about this,
>
> Thanks.
>
> > but in the meantime could you provide me the format in which you
> > want the log messages to be printed.
>
> I thought of
>
> [] ...
>
> where is the value given in the `FT_COMPONENT` macro,
> padded with spaces to ensure a uniform width. Example:
>
> [cffdriver] ...
> [psconv ] ...
> [sfobjs ] ...
>
> However, this should be freely adjustable – thus my request to make
> `{` and `}` configurable in the 'dlg' library.
>
> > Along with this, please share your thoughts on how you want to
> > toggle the TimeStamp and FT_COMPONENT features...
>
> What do you mean with 'toggle'?
>
>
> Werner
>
Re: Logging Library-GSOC
>> Oh yes, you can! Either you modify the source code of 'dlg' within
>> FreeType, or – which is better IMHO – you submit a feature request
>> or patch to the 'dlg' maintainers that allows control of the '{'
>> and '}' characters for marking tags. I see no reason why this must
>> be hard-coded.
>
> Ok, I will talk to the dlg's maintainer about this,
Thanks.
> but in the meantime could you provide me the format in which you
> want the log messages to be printed.
I thought of
[] ...
where is the value given in the `FT_COMPONENT` macro,
padded with spaces to ensure a uniform width. Example:
[cffdriver] ...
[psconv ] ...
[sfobjs ] ...
However, this should be freely adjustable – thus my request to make
`{` and `}` configurable in the 'dlg' library.
> Along with this, please share your thoughts on how you want to
> toggle the TimeStamp and FT_COMPONENT features...
What do you mean with 'toggle'?
Werner
Re: Logging Library-GSOC
*> Oh yes, you can! Either you modify the source code of 'dlg' within>
FreeType, or – which is better IMHO – you submit a feature request or>
patch to the 'dlg' maintainers that allows control of the '{' and '}'>
characters for marking tags. I see no reason why this must be> hard-coded.*
Ok, I will talk to the dlg's maintainer about this, but in the meantime
could
you provide me the format in which you want the log messages to be printed.
Along with this, please share your thoughts on how you want to toggle the
TimeStamp
and FT_COMPONENT features...
Thanks,
Priyesh
On Mon, Jul 6, 2020 at 3:32 PM Werner LEMBERG wrote:
>
> >> Of course. Please send a separate patch for these fixed so that I
> >> can apply it to master directly.
> >
> > Ok, I will provide you the patch once done...
>
> Thanks.
>
> >> Very nice! Do you have some data how large the slowdown is due to
> >> the additional code?
> >
> > No, As I haven't done software profiling before this... But I will
> > try it and provide you the required data...
>
> :-)
>
> >> I want
> >> [stream] ...
> >
> > It is indeed possible... dlg uses a feature flag (where user can
> > provide different features joined using the binary OR operator) to
> > control what needs to be printed along with actual log message (Time
> > Stamp, Tags, etc). Therefore we could check if `show_modules`
> > string is present in the `FT2_DEBUG` env and update the flag
> > accordingly.
>
> OK.
>
> > But, we cannot remove curly braces enclosing FT_COMPONENT as I am
> > using dlg_tags to print the FT_COMPONENT value and it is the default
> > way of dlg to output tags. Therefore, we could make Time Stamp and
> > FT_COMPONENT toggleable based on strings passed in `FT2_DEBUG` env
> > but cannot change the way in which they are printed.
>
> Oh yes, you can! Either you modify the source code of 'dlg' within
> FreeType, or – which is better IMHO – you submit a feature request or
> patch to the 'dlg' maintainers that allows control of the '{' and '}'
> characters for marking tags. I see no reason why this must be
> hard-coded.
>
>
> Werner
>
Re: [patch] Simplify ftconfig.h
On Mon, Jul 6, 2020 at 11:58 AM Werner LEMBERG wrote: > > > > Werner, please don't commit something if you think there are still > > problems in it, that's what code reviews are, > > Normally, I do that. However, I've already invested a lot of time in > writing ChangeLog entries... > > > See attached patch for a fix. > > Applied, thanks. Note, however, that there are still issues with > `make multi CC=c++` (I'm using g++ 7.5.0): > > c++ -ansi -pedantic \ > -Ifreetype2.compiled [...] \ > freetype2/src/base/ftsystem.c > In file included from freetype2/include/freetype/config/ftconfig.h:45:0, >from freetype2/src/base/ftsystem.c:29: > freetype2/include/freetype/config/public-macros.h:83:61: error: > expected unqualified-id before string constant >#define FT_EXPORT( x ) FT_PUBLIC_FUNCTION_ATTRIBUTE extern "C" x >^ > freetype2/include/freetype/fterrors.h:281:3: note: > in expansion of macro ‘FT_EXPORT’ > FT_EXPORT( const char* ) > ^ > > > Sorry about that. We need a better way to automatically check our > > builds. [...] I'll work on a proper rebuild-check script first > > though... github + travis-CI (and appveyor for windows) + coverity (static analysis) + coverage (unit testing coverage) i'm sure you can fork your repo in github. if you don't like github, gitlab should offer the same kind of tools Vincent Torri
Re: Logging Library-GSOC
>> Of course. Please send a separate patch for these fixed so that I
>> can apply it to master directly.
>
> Ok, I will provide you the patch once done...
Thanks.
>> Very nice! Do you have some data how large the slowdown is due to
>> the additional code?
>
> No, As I haven't done software profiling before this... But I will
> try it and provide you the required data...
:-)
>> I want
>> [stream] ...
>
> It is indeed possible... dlg uses a feature flag (where user can
> provide different features joined using the binary OR operator) to
> control what needs to be printed along with actual log message (Time
> Stamp, Tags, etc). Therefore we could check if `show_modules`
> string is present in the `FT2_DEBUG` env and update the flag
> accordingly.
OK.
> But, we cannot remove curly braces enclosing FT_COMPONENT as I am
> using dlg_tags to print the FT_COMPONENT value and it is the default
> way of dlg to output tags. Therefore, we could make Time Stamp and
> FT_COMPONENT toggleable based on strings passed in `FT2_DEBUG` env
> but cannot change the way in which they are printed.
Oh yes, you can! Either you modify the source code of 'dlg' within
FreeType, or – which is better IMHO – you submit a feature request or
patch to the 'dlg' maintainers that allows control of the '{' and '}'
characters for marking tags. I see no reason why this must be
hard-coded.
Werner
Re: [patch] Simplify ftconfig.h
> Werner, please don't commit something if you think there are still > problems in it, that's what code reviews are, Normally, I do that. However, I've already invested a lot of time in writing ChangeLog entries... > See attached patch for a fix. Applied, thanks. Note, however, that there are still issues with `make multi CC=c++` (I'm using g++ 7.5.0): c++ -ansi -pedantic \ -Ifreetype2.compiled [...] \ freetype2/src/base/ftsystem.c In file included from freetype2/include/freetype/config/ftconfig.h:45:0, from freetype2/src/base/ftsystem.c:29: freetype2/include/freetype/config/public-macros.h:83:61: error: expected unqualified-id before string constant #define FT_EXPORT( x ) FT_PUBLIC_FUNCTION_ATTRIBUTE extern "C" x ^ freetype2/include/freetype/fterrors.h:281:3: note: in expansion of macro ‘FT_EXPORT’ FT_EXPORT( const char* ) ^ > Sorry about that. We need a better way to automatically check our > builds. [...] I'll work on a proper rebuild-check script first > though... I don't worry about that right now, and please don't invest too much time here. This is something after a switch to a new build system IMHO. Werner
Re: [patch] Simplify ftconfig.h
On Mon, Jul 6, 2020 at 11:17 AM Nikolaus Waxweiler wrote: > Meson has a check-dist thing built in. Just saying > and other nice things. I'm eagerly waiting for a meson build Vincent Torri
Re: [patch] Simplify ftconfig.h
Meson has a check-dist thing built in. Just saying
Re: [patch] Simplify ftconfig.h
*Ouch* :-)
Werner, please don't commit something if you think there are still problems
in it, that's what code reviews are, and I'm currently on vacation, so
we've been lucky I could glimpse at my email and have time to fix it.
See attached patch for a fix. Sorry about that. We need a better way to
automatically check our builds. Note that the freetype2-demos issue didn't
appear on my workstation because I was doing an incremental build, and our
dependencies are so wrong that Make didn't catch the need to recompile the
demo sources, only relink the binaries. Yet another reason to change our
build.
I'll work on a proper rebuild-check script first though...
- David
Le lun. 6 juil. 2020 à 08:31, Werner LEMBERG a écrit :
> > [...] compilation of the the demo programs fails with
> >
> > freetype2-demos/src/ftbench.c: In function ‘face_requester’:
> > freetype2-demos/src/ftbench.c:165:5: warning:
> > implicit declaration of function ‘FT_UNUSED’
> [-Wimplicit-function-declaration]
> >FT_UNUSED( face_id );
> >^
>
> I've fixed this meanwhile. So only two issues for you, David :-)
>
>
> Werner
>
From 8abef31464aea930e3d947fa611845eff97d Mon Sep 17 00:00:00 2001
From: David Turner
Date: Mon, 6 Jul 2020 10:56:36 +0200
Subject: [build] Fix multi and C++ builds.
The following builds were failing due to previous changes:
make multi
make multi CC="c++"
This patch fixes the issues, which were missing includes to
get the right macro definitions in multi-build mode.
---
include/freetype/config/ftconfig.h | 3 ---
include/freetype/config/ftheader.h | 20
src/cache/ftccache.h | 2 +-
src/cache/ftcmru.h | 1 +
src/pcf/pcfutil.h | 2 +-
src/psaux/pserror.h| 1 +
src/psaux/psft.h | 2 +-
src/psaux/psstack.h| 1 +
src/sfnt/woff2tags.c | 2 +-
src/sfnt/woff2tags.h | 1 +
10 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/include/freetype/config/ftconfig.h b/include/freetype/config/ftconfig.h
index d59f29323..b464e0b78 100644
--- a/include/freetype/config/ftconfig.h
+++ b/include/freetype/config/ftconfig.h
@@ -45,9 +45,6 @@
#include
#include
-FT_END_HEADER
-
-
#endif /* FTCONFIG_H_ */
diff --git a/include/freetype/config/ftheader.h b/include/freetype/config/ftheader.h
index b028ece9c..28b5cc60c 100644
--- a/include/freetype/config/ftheader.h
+++ b/include/freetype/config/ftheader.h
@@ -30,10 +30,12 @@
/*encapsulated in an `extern "C" { .. }` block when included from a */
/*C++ compiler. */
/* */
-#ifdef __cplusplus
-#define FT_BEGIN_HEADER extern "C" {
-#else
-#define FT_BEGIN_HEADER /* nothing */
+#ifndef FT_BEGIN_HEADER
+# ifdef __cplusplus
+#define FT_BEGIN_HEADER extern "C" {
+# else
+# define FT_BEGIN_HEADER /* nothing */
+# endif
#endif
@@ -48,10 +50,12 @@
/*encapsulated in an `extern "C" { .. }` block when included from a */
/*C++ compiler. */
/* */
-#ifdef __cplusplus
-#define FT_END_HEADER }
-#else
-#define FT_END_HEADER /* nothing */
+#ifndef FT_END_HEADER
+# ifdef __cplusplus
+#define FT_END_HEADER }
+# else
+# define FT_END_HEADER /* nothing */
+# endif
#endif
diff --git a/src/cache/ftccache.h b/src/cache/ftccache.h
index 2996ee808..11698bb0e 100644
--- a/src/cache/ftccache.h
+++ b/src/cache/ftccache.h
@@ -19,7 +19,7 @@
#ifndef FTCCACHE_H_
#define FTCCACHE_H_
-
+#include
#include "ftcmru.h"
FT_BEGIN_HEADER
diff --git a/src/cache/ftcmru.h b/src/cache/ftcmru.h
index e7c2a8fad..ac4f9b126 100644
--- a/src/cache/ftcmru.h
+++ b/src/cache/ftcmru.h
@@ -45,6 +45,7 @@
#include
+#include
#ifdef FREETYPE_H
#error "freetype.h of FreeType 1 has been loaded!"
diff --git a/src/pcf/pcfutil.h b/src/pcf/pcfutil.h
index be986e756..a197c1559 100644
--- a/src/pcf/pcfutil.h
+++ b/src/pcf/pcfutil.h
@@ -31,7 +31,7 @@ THE SOFTWARE.
#include
#include FT_CONFIG_CONFIG_H
-
+#include
FT_BEGIN_HEADER
diff --git a/src/psaux/pserror.h b/src/psaux/pserror.h
index eb0a865e2..5738853fa 100644
--- a/src/psaux/pserror.h
+++ b/src/psaux/pserror.h
@@ -50,6 +50,7 @@
#include
+#include
#include "psft.h"
diff --git a/src/psaux/psft.h b/src/psaux/psft.h
index 902983ed7..3da454e60 100644
--- a/src/psaux/psft.h
+++ b/src/psaux/psft.h
@@ -40,9 +40,9 @@
#define PSFT_H_
+#include
#include "pstypes.h"
-
/* TODO: disable asserts for now */
#define CF2_NDEBUG
diff --git a/src/psaux/psstack.h b/src/psaux/psstack.h
index 18cd39bc6..b9ef9edf1 100644
--- a/src/psaux/psstack.h
+++ b/src/psaux/psstack.h
@@ -39,6 +39,7 @@
#ifndef PSSTACK_H_
#define PSSTACK_H_
Re: Logging Library-GSOC
*> Of course. Please send a separate patch for these fixed so that I can>
apply it to master directly.*
Ok, I will provide you the patch once done...
*> Very nice! Do you have some data how large the slowdown is due to the>
additional code?*
No,
As I haven't done software profiling before this...
But I will try it and provide you the required data...
*> Now let's pretend I'm Joe User, and I want a different logging format.>
Instead of having> [12:03:56 {stream}] ...> I want> [stream] ...> What
must be done? [Actually, this is the default format I want to> have if the
`FT2_DEBUG` environment variable contains the string> `show_modules` (or
`-v`, or whatever; this isn't implemented yet).]*
It is indeed possible...
dlg uses a feature flag(where user can provide different features
joined using the binary *OR *operator)
to control what needs to be printed along with actual log message(Time
Stamp, Tags, etc).
Therefore we could check if `show_modules` string is present in the
`FT2_DEBUG` env and update the
flag accordingly.
But, we cannot remove curly braces enclosing FT_COMPONENT as I am
using *dlg_tags
*to print the
FT_COMPONENT value and it is the default way of dlg to output tags.
Therefore, we could make Time Stamp and FT_COMPONENT toggleable based on
strings passed in `FT2_DEBUG` env
but cannot change the way in which they are printed.
Thanks,
Priyesh
On Mon, Jul 6, 2020 at 1:01 PM Werner LEMBERG wrote:
>
> > I have added some changes to produce the desired output using the
> > previous approach specified by you. With this approach, I have to
> > make very little changes in some FT_TRACE calls for better
> > indentation. Would that be OK with you?
>
> Of course. Please send a separate patch for these fixed so that I can
> apply it to master directly.
>
> > I am attaching a log file generated by the ftview.c demo program
> > representing the new changes...
>
> Very nice! Do you have some data how large the slowdown is due to the
> additional code?
>
> Now let's pretend I'm Joe User, and I want a different logging format.
> Instead of having
>
> [12:03:56 {stream}] ...
>
> I want
>
> [stream] ...
>
> What must be done? [Actually, this is the default format I want to
> have if the `FT2_DEBUG` environment variable contains the string
> `show_modules` (or `-v`, or whatever; this isn't implemented yet).]
>
>
> Werner
>
Re: Logging Library-GSOC
> I have added some changes to produce the desired output using the
> previous approach specified by you. With this approach, I have to
> make very little changes in some FT_TRACE calls for better
> indentation. Would that be OK with you?
Of course. Please send a separate patch for these fixed so that I can
apply it to master directly.
> I am attaching a log file generated by the ftview.c demo program
> representing the new changes...
Very nice! Do you have some data how large the slowdown is due to the
additional code?
Now let's pretend I'm Joe User, and I want a different logging format.
Instead of having
[12:03:56 {stream}] ...
I want
[stream] ...
What must be done? [Actually, this is the default format I want to
have if the `FT2_DEBUG` environment variable contains the string
`show_modules` (or `-v`, or whatever; this isn't implemented yet).]
Werner
Re: [patch] Simplify ftconfig.h
> [...] compilation of the the demo programs fails with > > freetype2-demos/src/ftbench.c: In function ‘face_requester’: > freetype2-demos/src/ftbench.c:165:5: warning: > implicit declaration of function ‘FT_UNUSED’ > [-Wimplicit-function-declaration] >FT_UNUSED( face_id ); >^ I've fixed this meanwhile. So only two issues for you, David :-) Werner
Re: Logging Library-GSOC
> > Since debugging isn't time critical it might be necessary to add
> > an additional step that scans tracing messages for newline
> > characters, then massaging the output by inserting the time stamp.
> > In other words, all occurrences of `\n` should be replaced with
> > `\n[time stamp] ` or something similar.
>
> I also came up with the same idea but thought that string comparison
> will take plenty amount of time, therefore, I dropped this idea...
> But, as you said so I will try to implement it...
Do you have a better idea? I could only come up with another set of
tracing macros like `FT_TRACEC[0-7]` ('C' for continuing) that don't
emit a final newline. This would imply *a lot* of (mostly mechanical)
changes in the source code. It wouldn't really uglify the source
code, though, but I think a solution that doesn't necessitate this
distinction is preferable since easier to use.
Werner
