From: Barry S. <che...@ch...> - 2012-07-18 03:00:11
|
Is there still a reason to handle freetype source directly, or was that, say, a way of bypassing that some OSes had the TrueType interpreter turned off in their freetype package? Do any still do? (OT: Some of these packages such as Pango are so pkg-config dependent that I changed my mind: I’m _not_ going to include hacks for at least some packages that are supposed to have .pc files.) |
From: Khaled H. <kha...@eg...> - 2012-07-18 07:28:45
|
On Tue, Jul 17, 2012 at 10:00:03PM -0500, Barry Schwartz wrote: > Is there still a reason to handle freetype source directly, or was > that, say, a way of bypassing that some OSes had the TrueType > interpreter turned off in their freetype package? Do any still do? >From README-unix: *** FontForge also needs to have the freetype sources available to it *** *** when it builds (it needs some internal include files). The configure *** *** script can usually figure this out, but it is very time-consuming *** *** you might want to say $ ./configure --with-freetype-src=<dir> *** *** where <dir> is the top-level freetype source directory *** Which seems to be still valid. Anyway, please, please don't do the 'find /' hack in the new build. Regards, Khaled |
From: Dave C. <da...@la...> - 2012-07-18 10:15:02
|
On 18 July 2012 08:28, Khaled Hosny <kha...@eg...> wrote: > Anyway, please, please don't do the 'find /' hack in the new build. lol :) While this _is_ effective, I'd prefer that it simply check the common default places and then give up quickly. |
From: Barry S. <che...@ch...> - 2012-07-18 15:57:58
|
Dave Crossland <da...@la...> skribis: > On 18 July 2012 08:28, Khaled Hosny <kha...@eg...> wrote: > > Anyway, please, please don't do the 'find /' hack in the new build. > > lol :) While this _is_ effective, I'd prefer that it simply check the > common default places and then give up quickly. It's the most annoying thing in the entire world. :) My unfamiliarity is because I don't ever deal with TrueType directly. |
From: Dave C. <da...@la...> - 2012-07-18 18:59:40
|
On 18 July 2012 19:45, Barry Schwartz <che...@ch...> wrote: > This is a tricky feature to build, and > will not be used by a casual user. I diagree :) Its very useful to have freetype linked in because then you can preview what your type will rasterize as - using the Glyph window, Grid Fit menu. |
From: Barry S. <che...@ch...> - 2012-07-18 19:13:15
|
Dave Crossland <da...@la...> skribis: > On 18 July 2012 19:45, Barry Schwartz <che...@ch...> wrote: > > This is a tricky feature to build, and > > will not be used by a casual user. > > I diagree :) Its very useful to have freetype linked in because then > you can preview what your type will rasterize as - using the Glyph > window, Grid Fit menu. If you are generating CFF fonts then you have no idea how it will be rasterized, because that's left up to the rasterizer. You can try different rasterizers and see how it comes out, but they'll all be different. If you are generating TrueType fonts and spending time tweaking rasterization, then you are designing rasterizers again and again and again, not typefaces. Much human lifespan has been wasted. :) It can be "yes" by default if freetype source is included, otherwise I think it ought to be "no" by default, because it is a tricky feature to build. |
From: Khaled H. <kha...@eg...> - 2012-07-18 19:41:27
|
On Wed, Jul 18, 2012 at 01:45:51PM -0500, Barry Schwartz wrote: > Dave Crossland <da...@la...> skribis: > > On 18 July 2012 18:21, Daniel Kahn Gillmor <dk...@fi...> wrote: > > > a) use a ./configure argument or environment variable provided by the > > > user to locate the freetype source explicitly > > > > This does seem like the simplest thing. > > How about this: > > (a) --enable-<feature-name> > > (instead of --with, because is a feature, not an optional > dependency) > > The default is --disable. This is a tricky feature to build, and > will not be used by a casual user. I haven't used it, for > instance, and haven't ever built my fontforge using freetype > sources. > > (b) Provide an environment variable to specify the sources > location. (Putting optional paths in environment variables > provides a lot of flexibility for people familiar with how to > run an autoconf-generated configure script.) > > (c) Look in ${top_builddir} followed by ${top_srcdir}. Include a > "known good" freetype version in ${top_srcdir}. That sounds like a good plan, flexible enough to cover all use cases and no messing with system directories. Regards, Khaled |
From: Barry S. <che...@ch...> - 2012-07-18 20:00:53
|
Khaled Hosny <kha...@eg...> skribis: > On Wed, Jul 18, 2012 at 01:45:51PM -0500, Barry Schwartz wrote: > > Dave Crossland <da...@la...> skribis: > > > On 18 July 2012 18:21, Daniel Kahn Gillmor <dk...@fi...> wrote: > > > > a) use a ./configure argument or environment variable provided by the > > > > user to locate the freetype source explicitly > > > > > > This does seem like the simplest thing. > > > > How about this: > > > > (a) --enable-<feature-name> > > > > (instead of --with, because is a feature, not an optional > > dependency) > > > > The default is --disable. This is a tricky feature to build, and > > will not be used by a casual user. I haven't used it, for > > instance, and haven't ever built my fontforge using freetype > > sources. > > > > (b) Provide an environment variable to specify the sources > > location. (Putting optional paths in environment variables > > provides a lot of flexibility for people familiar with how to > > run an autoconf-generated configure script.) > > > > (c) Look in ${top_builddir} followed by ${top_srcdir}. Include a > > "known good" freetype version in ${top_srcdir}. > > That sounds like a good plan, flexible enough to cover all use cases and > no messing with system directories. Revised suggestion: (a) Same as above. (b) Same as above. (c) The user still has to download freetype separately, but ff will look in ${top_builddir} and then ${top_srcdir} for "freetype/", which can be a symlink. That way you can easily have multiple versions of freetype in your ${top_srcdir} if you are hacking on ff; or if you are hacking on ff you can put different symlinks in different ${top_builddir} (out-of-source builds). Something like a Gentoo ebuild should probably use the environment variable instead, because it is the most readable method. |
From: vernon a. <ve...@ne...> - 2012-07-18 20:13:30
|
Dave, You have an /opt directory?! You sure about that? on OSX? if i run ./configure --with-pango-headers=/usr/local/Cellar/pango/1.30.1/include/ --with-pango-lib=/usr/local/Cellar/pango/1.30.1/lib/ i get this error; ( cd Unicode ; make ) make[1]: `../libgunicode.la' is up to date. ( cd gutils ; make ) /bin/sh ../libtool --mode=compile gcc -g -O2 -I/usr/local/include/freetype2/ -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/include/libxml2/ /usr/local/Cellar/pango/1.30.1/include/ -arch x86_64 -I/usr/include/python2.7 -I../inc -I../inc -I/usr/pkg/include -I/usr/pkg/include/giflib -Wmissing-prototypes -Wunused -Wimplicit -Wreturn-type -Wparentheses -Wformat -Wchar-subscripts -DNOTHREADS -DHAVE_CONFIG_H -DLIBDIR='"/usr/local/lib"' -c gioftp.c libtool: compile: gcc -g -O2 -I/usr/local/include/freetype2/ -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/include/libxml2/ /usr/local/Cellar/pango/1.30.1/include/ -arch x86_64 -I/usr/include/python2.7 -I../inc -I../inc -I/usr/pkg/include -I/usr/pkg/include/giflib -Wmissing-prototypes -Wunused -Wimplicit -Wreturn-type -Wparentheses -Wformat -Wchar-subscripts -DNOTHREADS -DHAVE_CONFIG_H -DLIBDIR=\"/usr/local/lib\" -c gioftp.c -fno-common -DPIC -o .libs/gioftp.o gioftp.c: In function 'GIO_dispatch': gioftp.c:616: warning: implicit declaration of function 'pthread_mutex_lock' gioftp.c:616: error: 'struct stdfuncs' has no member named 'hostacccess_mutex' gioftp.c:626: warning: implicit declaration of function 'pthread_mutex_unlock' gioftp.c:626: error: 'struct stdfuncs' has no member named 'hostacccess_mutex' make[1]: *** [gioftp.lo] Error 1 make: *** [libgutils] Error 2 if i run ./configure without those 2 args, then all builds fine :-/ -v On 18 Jul 2012, at 20:27, Dave Crossland wrote: > I couldn't figure out how to fix this, so I made these symlinks: > > /opt/local/lib/libpng.2.dylib -> /opt/X11/lib/libpng15.dylib > > /opt/local/lib/libpangocairo-1.0.0.dylib -> /usr/local/lib/libpango-1.0.0.dylib |
From: Khaled H. <kha...@eg...> - 2012-07-18 20:31:27
|
On Wed, Jul 18, 2012 at 09:13:20PM +0100, vernon adams wrote: > Dave, You have an /opt directory?! You sure about that? on OSX? > > if i run ./configure --with-pango-headers=/usr/local/Cellar/pango/1.30.1/include/ --with-pango-lib=/usr/local/Cellar/pango/1.30.1/lib/ AFAIK, this should be the value of `pkg-config --cflags pango` and `pkg-config --libs pango`, respectively, but I doubt pkg-config will work with your unusual install path. Regards, Khaled |
From: vern a. <ve...@ne...> - 2012-07-18 20:33:37
|
Yes, i should probably dump the homebrew pango, and install it from source myself. thanks -v On 18 Jul 2012, at 21:31, Khaled Hosny wrote: > On Wed, Jul 18, 2012 at 09:13:20PM +0100, vernon adams wrote: >> Dave, You have an /opt directory?! You sure about that? on OSX? >> >> if i run ./configure --with-pango-headers=/usr/local/Cellar/pango/1.30.1/include/ --with-pango-lib=/usr/local/Cellar/pango/1.30.1/lib/ > > AFAIK, this should be the value of `pkg-config --cflags pango` and > `pkg-config --libs pango`, respectively, but I doubt pkg-config will > work with your unusual install path. > > Regards, > Khaled |
From: James C. <cl...@jh...> - 2012-07-18 22:15:36
|
[picking a semi-random email to reply to on this thread -JimC] > (b) Provide an environment variable to specify the sources > location. ff already supports --with-freetype-src=$PATH_TO_FT_SRC. Why change what works? (On gentoo, the ft ebuild store the required extras in /usr/include/freetype2/internal4fontforge/ and pass that path to --with-freetype-src when configuring ff.) -JimC -- James Cloos <cl...@jh...> OpenPGP: 1024D/ED7DAEA6 |
From: Barry S. <che...@ch...> - 2012-07-18 23:26:22
|
James Cloos <cl...@jh...> skribis: > [picking a semi-random email to reply to on this thread -JimC] > > > (b) Provide an environment variable to specify the sources > > location. > > ff already supports --with-freetype-src=$PATH_TO_FT_SRC. Yes, I know. > Why change what works? To improve on what works, if I can. IMO this is an optional feature to a greater degree than it is an optional dependency, so I'd rather --enable-feature than use --with-dependency. I feel the configure script should be informative by design. (I hate reading manuals.) Also the script should look more GNUish and pkg-configish than it does, so it seems familiar. Also there are practical reasons to prefer an environment variable to locate sources. For instance, read about "config.site" files in the autoconf manual. > (On gentoo, the ft ebuild store the required extras in > > /usr/include/freetype2/internal4fontforge/ None of that would have to change. > and pass that path to --with-freetype-src when configuring ff.) Ebuilds are easy to change. If you use --enable-option-checking=fatal then most changes, including minor ones like sticking an extra hyphen in an option to make it more GNUish, will cause an old configure command to abort. Autoconf is our friend. :) However, this feature is so tricky and likely to upset somebody that I think I should put in every solution except searching, even though normally I prefer to avoid redundancy. Thus: --enable-feature[=DIR] bla bla bla bla ... --with-freetype-source[=DIR] synonym for --enable-feature ... FREETYPE_SOURCE bla bla bla bla Then the feature is documented by design, and the options look both more GNUish and more Pkg-configish. I should leave out any kind of default directory, I think. If you don't want to type --with-freetype-source=DIR all the time, you can set up a config.site file that points to your freetype sources. Look it up in the autoconf manual. The ebuild should use FREETYPE_SOURCE and first check if it has been set by package.env or make.conf (or bashrc in Paludis), in case the user wants to use his or her own sources. |
From: Khaled H. <kha...@eg...> - 2012-07-18 10:45:57
|
On Wed, Jul 18, 2012 at 10:14:21AM +0000, Dave Crossland wrote: > On 18 July 2012 08:28, Khaled Hosny <kha...@eg...> wrote: > > Anyway, please, please don't do the 'find /' hack in the new build. > > lol :) While this _is_ effective, I'd prefer that it simply check the > common default places and then give up quickly. There is no default places for freetype sources so it should just gove up unless the switch is explicitly given. May be checking for $SRC/freetype (and verifying the needed files are there) would be an acceptable fallback. Regards, Khaled |
From: Khaled H. <kha...@eg...> - 2012-07-18 11:22:07
|
On Wed, Jul 18, 2012 at 11:11:30AM +0000, Dave Crossland wrote: > On 18 July 2012 11:45, Khaled Hosny <kha...@eg...> wrote: > > On Wed, Jul 18, 2012 at 10:14:21AM +0000, Dave Crossland wrote: > >> On 18 July 2012 08:28, Khaled Hosny <kha...@eg...> wrote: > >> > Anyway, please, please don't do the 'find /' hack in the new build. > >> > >> lol :) While this _is_ effective, I'd prefer that it simply check the > >> common default places and then give up quickly. > > > > There is no default places for freetype sources so it should just gove > > up unless the switch is explicitly given. May be checking for > > $SRC/freetype (and verifying the needed files are there) would be an > > acceptable fallback. > > http://packages.debian.org/search?keywords=libfreetype6-dev wouldn't work? No, FontForge is using internal headers so it needs the full source not only the public headers. I think FontForge is using FreeType here in a "special" way that is not a indented use case. May be it is possible to get FreeType to expose the API it needs, but I know very little. Regards, Khaled |
From: Dave C. <da...@la...> - 2012-07-18 11:23:49
|
Okay, thanks for clarifying -- I now agree with Khaled. |
From: Werner L. <wl...@gn...> - 2012-07-19 23:08:28
|
> [...] FontForge is using internal headers so it needs the full > source not only the public headers. I think FontForge is using > FreeType here in a "special" way that is not a indented use case. Correct. > May be it is possible to get FreeType to expose the API it needs, > [...] I won't do that. FontForge *really* uses deep internals of FreeType. Werner |
From: Dave C. <da...@la...> - 2012-07-18 11:12:05
|
On 18 July 2012 11:45, Khaled Hosny <kha...@eg...> wrote: > On Wed, Jul 18, 2012 at 10:14:21AM +0000, Dave Crossland wrote: >> On 18 July 2012 08:28, Khaled Hosny <kha...@eg...> wrote: >> > Anyway, please, please don't do the 'find /' hack in the new build. >> >> lol :) While this _is_ effective, I'd prefer that it simply check the >> common default places and then give up quickly. > > There is no default places for freetype sources so it should just gove > up unless the switch is explicitly given. May be checking for > $SRC/freetype (and verifying the needed files are there) would be an > acceptable fallback. http://packages.debian.org/search?keywords=libfreetype6-dev wouldn't work? |
From: Barry S. <che...@ch...> - 2012-07-18 16:12:26
|
Khaled Hosny <kha...@eg...> skribis: > On Wed, Jul 18, 2012 at 10:14:21AM +0000, Dave Crossland wrote: > > On 18 July 2012 08:28, Khaled Hosny <kha...@eg...> wrote: > > > Anyway, please, please don't do the 'find /' hack in the new build. > > > > lol :) While this _is_ effective, I'd prefer that it simply check the > > common default places and then give up quickly. > > There is no default places for freetype sources so it should just gove > up unless the switch is explicitly given. May be checking for > $SRC/freetype (and verifying the needed files are there) would be an > acceptable fallback. There has been a default place for decades, and that's /usr/src/. My inclination is to look for /usr/src/freetype[-VERSION]/ and otherwise require the path be given. (Now I just realized that at least one ebuild I have written ought to be sticking something in /usr/src that it stuck elsewhere. D'oh!) |
From: Khaled H. <kha...@eg...> - 2012-07-18 16:22:43
|
On Wed, Jul 18, 2012 at 11:12:15AM -0500, Barry Schwartz wrote: > Khaled Hosny <kha...@eg...> skribis: > > On Wed, Jul 18, 2012 at 10:14:21AM +0000, Dave Crossland wrote: > > > On 18 July 2012 08:28, Khaled Hosny <kha...@eg...> wrote: > > > > Anyway, please, please don't do the 'find /' hack in the new build. > > > > > > lol :) While this _is_ effective, I'd prefer that it simply check the > > > common default places and then give up quickly. > > > > There is no default places for freetype sources so it should just gove > > up unless the switch is explicitly given. May be checking for > > $SRC/freetype (and verifying the needed files are there) would be an > > acceptable fallback. > > There has been a default place for decades, and that's /usr/src/. My > inclination is to look for /usr/src/freetype[-VERSION]/ and otherwise > require the path be given. I just realised I've such a thing, put I never put anything there for ages (since I moved to Debian, I think). That would be a good default indeed. Regards, Khaled |
From: Dave C. <da...@la...> - 2012-07-18 19:28:47
|
On 18 July 2012 20:13, Barry Schwartz <che...@ch...> wrote: > It can be "yes" by default if freetype source is included, otherwise I > think it ought to be "no" by default, because it is a tricky feature > to build. But where should freetype source be for you to consider it 'included'? |
From: Barry S. <che...@ch...> - 2012-07-18 19:53:17
|
Dave Crossland <da...@la...> skribis: > On 18 July 2012 20:13, Barry Schwartz <che...@ch...> wrote: > > It can be "yes" by default if freetype source is included, otherwise I > > think it ought to be "no" by default, because it is a tricky feature > > to build. > > But where should freetype source be for you to consider it 'included'? Probably you should have to download freetype separately. When packages include sources for things like freetype -- like Unicon does with gdb or used to do up to the last time I build Unicon -- it is annoying. (Though that actually is worse because it took patches to use the system gdb.) |
From: <ms...@an...> - 2012-07-18 16:20:37
|
On Wed, 18 Jul 2012, Barry Schwartz wrote: > There has been a default place for decades, and that's /usr/src/. My > inclination is to look for /usr/src/freetype[-VERSION]/ and otherwise > require the path be given. /usr/local/src has been standard almost at long. I think it's silly not to look there. However, almost any default would be better than invoking "find /", which is a borderline malicious thing for a configure script to do. -- Matthew Skala ms...@an... People before principles. http://ansuz.sooke.bc.ca/ |
From: Just F. B. <moz...@ya...> - 2012-07-18 16:56:51
|
于 07/19/2012 12:22 AM, Khaled Hosny 写道: > On Wed, Jul 18, 2012 at 11:12:15AM -0500, Barry Schwartz wrote: >> Khaled Hosny<kha...@eg...> skribis: >>> On Wed, Jul 18, 2012 at 10:14:21AM +0000, Dave Crossland wrote: >>>> On 18 July 2012 08:28, Khaled Hosny<kha...@eg...> wrote: >>>>> Anyway, please, please don't do the 'find /' hack in the new build. >>>> >>>> lol :) While this _is_ effective, I'd prefer that it simply check the >>>> common default places and then give up quickly. >>> >>> There is no default places for freetype sources so it should just gove >>> up unless the switch is explicitly given. May be checking for >>> $SRC/freetype (and verifying the needed files are there) would be an >>> acceptable fallback. >> >> There has been a default place for decades, and that's /usr/src/. My >> inclination is to look for /usr/src/freetype[-VERSION]/ and otherwise >> require the path be given. > > I just realised I've such a thing, put I never put anything there for > ages (since I moved to Debian, I think). That would be a good default > indeed. > How about `locate`? That will return a quick result, accurate or not. |
From: Barry S. <che...@ch...> - 2012-07-18 17:06:04
|
Just Fill Bugs <moz...@ya...> skribis: > How about `locate`? That will return a quick result, accurate or not. It's a security nightmare; someone could put malicious sources somewhere, and fontforge would just forge ahead and use them. And it leaves as a mystery what sources you actually will get, especially if you are a freetype developer. |