> The amalgamation tool does not understand C style comments so it
> gets confused when they appear on an #include line.
Hmm. Such a tool should be able to handly any valid C (or C++)
code...
> I guess I could add support for it but that will only make the tool
> more complex and increase the w
>Date: Fri, 24 Feb 2012 12:29:13 +0100 (CET)
>From: Werner LEMBERG
>Subject: Re: [ft-devel] FreeType patches to support amalgamation #2
>
>> One more minor set of changes, I moved an inline comment to the
>> previous line on a couple of #include lines.
>
>Wh
> One more minor set of changes, I moved an inline comment to the
> previous line on a couple of #include lines.
What is this change set good for, except cosmetics?
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.no
> Yes. So far there are 6 sets of changes, using the naming
> conventions that you recommended. These patches were created off an
> unmodified copy of the publicly available FreeType
> 2.4.8. Unfortunately I'm using SVN but the patches should still be
> applicable (?)
Thanks for the patches! I'
> Putting the prefix or postfix to all names, we can avoid the
> conflicts, but it makes the names longer, and it makes the sources
> eye-unfriendly (especially for the die-hard VT100 emulator users
> like me).
I usually strictly enforce a 78 character per line limit, so I also
want to avoid over
Alan Coopersmith wrote:
> Using anything but a shared library for FreeType just seems to be begging
> for pain [...]
Unlike many high-profile packages, Freetype is also used on (mostly
embedded) platforms where shared libraries just do not exist.
Also if some vendor has a design which, perhaps fo
Hi,
For first, I state that I have no objection against the decision by
Werner, because now the time he spends for the maintenance of FreeType2
(in official branch) is longer than those of other FreeType2 developers
(maybe except of David Turner).
But, if I just talk about the idea to change prog
> Unless I've misunderstood, It seems to me that the changes being
> made are not to amalgamate FreeType into a couple of files, but just
> to rename some stuff/change some #defines to make this possible for
> another tool to optionally do.
Exactly. No need to further discuss that. I've accepte
> How about a shared header file if those modules share a structure?
> Don't you see that this patch set is just a pile of pure stinking
> crap???
Alexei, your comments are at the border of insults. Please don't do
that! We already know that you don't like the patches. It doesn't
help at all i
On Tue, Feb 21, 2012 at 11:54 AM, Vinnie wrote:
>
>
>> From: Alexei Podtelezhnikov
>> Sent: Tuesday, February 21, 2012 8:28 AM
>>
>> It is hard to believe that there are people who'll dive into font rendering
>> without first learning how to use multiple files and libraries in a project.
>
> I ag
> From: Alexei Podtelezhnikov
> Sent: Tuesday, February 21, 2012 8:28 AM
>
> It is hard to believe that there are people who'll dive into font rendering
> without first learning how to use multiple files and libraries in a project.
I agree, it is hard to believe but that's just how it is. For s
On Tue, Feb 21, 2012 at 11:03 AM, Chris Morgan wrote:
> Hey. This kind of response isn't cool man.
>
> If Vinnie's patches disambiguate and otherwise clarify the code then
> they are good changes, even if it enables him to do things that we
> find odd.
There is nothing ambiguous in FreeType code.
On Tue, Feb 21, 2012 at 12:07 PM, Dmitry Timoshkov wrote:
> Vinnie wrote:
>
>> > How about providing a single precompiled library file for these people?
>>
>> That would only work for one particular build environment, and within that
>> environment, only one target. For example, debug, or release
On Tue, Feb 21, 2012 at 10:44 AM, Vinnie wrote:
>> Date: Tue, 21 Feb 2012 08:02:43 -0500
>
>> From: Alexei Podtelezhnikov
>>
>> You planing this for Stone Age people who do not know how to use
>> make. I rest my case.
>
> Actually, that is true.
>
> My target audience includes musicians or artist
> From: Alan Coopersmith
>
> Using anything but a shared library for FreeType just seems to be begging
> for pain everytime FreeType has to issue a security fix or other critical
> fix, and suddenly you need to redeliver every single application with the
> FreeType code embedded, instead of one c
Vinnie wrote:
> > How about providing a single precompiled library file for these people?
>
> That would only work for one particular build environment, and within that
> environment, only one target. For example, debug, or release. Or 32 bit versus
> 64 bit. If the resulting FreeType library we
On 02/21/12 05:02 AM, Alexei Podtelezhnikov wrote:
All this work is from Stone Age, when noone shared and everyone
only used a single file and a single command to build something.
Using anything but a shared library for FreeType just seems to be begging
for pain everytime FreeType has to issue
On Tue, Feb 21, 2012 at 11:01 AM, Vinnie wrote:
>> From: Dmitry Timoshkov
>
>> Sent: Tuesday, February 21, 2012 8:53 AM
>>
>>> With an amalgamated version of FreeType I can add support for hinted
>>> fonts to my open source offerings, while including the entire FreeType
>>> distribution as a s
Hey. This kind of response isn't cool man.
If Vinnie's patches disambiguate and otherwise clarify the code then
they are good changes, even if it enables him to do things that we
find odd. If there are common structures that should be used then that
is valid feedback, please clarify which ones etc
> From: Dmitry Timoshkov
> Sent: Tuesday, February 21, 2012 8:53 AM
>
>> With an amalgamated version of FreeType I can add support for hinted
>> fonts to my open source offerings, while including the entire FreeType
>> distribution as a single source file instead of a large tree.
>
> How abo
Vinnie wrote:
> With an amalgamated version of FreeType I can add support for hinted
> fonts to my open source offerings, while including the entire FreeType
> distribution as a single source file instead of a large tree.
How about providing a single precompiled library file for these people?
-
> Date: Tue, 21 Feb 2012 08:02:43 -0500
> From: Alexei Podtelezhnikov
>
> You planing this for Stone Age people who do not know how to use
> make. I rest my case.
Actually, that is true.
My target audience includes musicians or artists who are beginning
to dabble in C / C++ programming. The are
Unless I've misunderstood, It seems to me that the changes being made are not
to amalgamate FreeType into a couple of files, but just to rename some
stuff/change some #defines to make this possible for another tool to optionally
do.
If so, I really can't see what the problem is and why you're b
How about a shared header file if those modules share a structure?
Don't you see that this patch set is just a pile of pure stinking crap???
On Tue, Feb 21, 2012 at 9:56 AM, Vinnie wrote:
> Werner:
>
> 2012-02-20 Vinnie Falco
>
>
> ftgrays.c, ftraster.c: Undefine RAS_ARG* and RAS_VAR*, rename
Werner:
2012-02-20 Vinnie Falco
ftgrays.c, ftraster.c: Undefine RAS_ARG* and RAS_VAR*, rename PRaster, TRaster
Attached is the change you requested to undefined the RAS_* macros.
Thanks,
Vinnie
4.patch
Description: Binary data
___
Freetype-dev
Alexei Podtelezhnikov wrote:
> All this work is from Stone Age, when noone shared and everyone
> only used a single file and a single command to build something.
I tend to agree, I somehow doubt that there is a single project out there
that would even consider accepting this kind of patches.
--
All this work is from Stone Age, when noone shared and everyone
only used a single file and a single command to build something.
You will make people who borrow from FreeType miserable and make
them curse at you for renaming stuff for no good reason whatsoever.
Yes, taking smooth out of FreeType f
On Tue, Feb 21, 2012 at 4:11 AM, Antoine Leca
wrote:
> Alexei Podtelezhnikov wrote:
>> Why do you butcher perfectly legal code C-code?
>> You problem is in the tool - not it in FreeType.
> This is not fair. The exercise do show some areas in Freetype which code
> will be clearly made better after
Alexei Podtelezhnikov wrote:
> Why do you butcher perfectly legal code C-code?
> You problem is in the tool - not it in FreeType.
This is not fair. The exercise do show some areas in Freetype which code
will be clearly made better after the corrections proposed by Vinnie.
Examples are the #undef pp
Hello Vinnie!
Thanks a lot for your work. I only have a single comment; everything
else looks fine.
In file `4.patch':
> -#define RAS_ARGS /* void */
> -#define RAS_ARG/* void */
> +#define black_RAS_ARGS /* void */
> +#define black_RAS_ARG/* void */
>
> -#define
On Mon, Feb 20, 2012 at 5:45 PM, Werner LEMBERG wrote:
>
>> Again, I'll say that this is just such a bizarre objective that you
>> HAVE TO justify this and tell which platform on Earth needs it.
>
> ??? It's not related to a specific platform at all. It's a matter of
> an easy way to distribute
> Again, I'll say that this is just such a bizarre objective that you
> HAVE TO justify this and tell which platform on Earth needs it.
??? It's not related to a specific platform at all. It's a matter of
an easy way to distribute the FreeType code with a very few number of
files.
> Remember i
>> To be honest, I am perplexed by this amalgamation exercise. All of
>> this apparently needed because some obscure "in-house" tool does
>> not know how to resolve the name conflicts.
I don't think so.
>> Teach the damn tool how to resolve the name conflicts by adding
>> prefixes or suffixes!
You again manage to present this as a legitimate goal :)
It is your tool that breaks the code :) You are not fooling me here.
Again, I'll say that this is just such a bizarre objective that
you HAVE TO justify this and tell which platform on Earth
needs it. Remember it has to be a platform which
> From: Alexei Podtelezhnikov
>Sent: Monday, February 20, 2012 12:15 PM
>Subject: Re: [ft-devel] FreeType patches to support amalgamation
>
>To be honest, I am perplexed by this amalgamation exercise.
>All of this apparently needed because some obscure "in-house"
To be honest, I am perplexed by this amalgamation exercise.
All of this apparently needed because some obscure "in-house"
tool does not know how to resolve the name conflicts.
Teach the damn tool how to resolve the name conflicts
by adding prefixes or suffixes!
Why do you butcher perfectly legal
36 matches
Mail list logo
