Hi,
While doing general maintenance I ended up cleaning all the different source
files we generate during build (fclang.h, fccase.h, fcglyhnames.h, fcarch.h).
Of those four, the first three are static and I decide to ship in the
tarball. This should make cross-compiling a tad bit easier.
I figured that configure.in already tries to find CC_FOR_BUILD and
EXEEXT_FOR_BUILD. And surprisingly, those are used to compile and run
fc-arch.c, which means the architecture detected will be the build
architecture, not the target!
I''m guessing that the end result have been that all the embedded
companies
commpiling fontconfig for ARM have been getting cache files with an x86
extension, but since those caches were not shared, this didn''t cause
any problem.
To fix this, I''m thinking about getting rid of fc-arch.c and move the
logic
into a compile-time header file. Something like:
#define CHECK_ARCH(arch, sizeof_Align, sizeof_char, sizeof_int, sizeof_long) \
(sizeof (FcAlign) == sizeof_Align && \
sizeof (char) == sizeof_char && \
sizeof (int) == sizeof_int && \
sizeof (long) == sizeof_long) ? (arch)
#define FC_ARCHITECTURE (\
CHECK_ARCH("x86", 4,1,4,4) : \
CHECK_ARCH("x86-64", 8,1,4,8) : \
"unknown" )
This should work fine. The only problem is, it''s not very friendly to
new
architectures:
1) falls back to "unknown". Can''t err. Maybe if I use
something like:
extern char *unknown_architecture;
#define FC_ARCHITECTURE (\
CHECK_ARCH("x86", 4,1,4,4) : \
CHECK_ARCH("x86-64", 8,1,4,8) : \
unknown_architecture )
it may fail at link time. But may also fail if compiled without
optimizations? Donno.
Another option is to move all the logic to configure. AC_CHECK_SIZEOF these
days can find sizeof(type) even when cross-compiling (it binary searches!).
In fact, there''s even AC_COMPUTE_INT() which gets the number out to a
shell
variable. So we can find all the sizes we use and do the arch-finding magic
in configure. This has the following benefits:
- It errs during configure if arch is unknown, and will print instructions
and the signature to add. Good.
- Arch can be overridden using a configure argument. Good.
- We can use the arch name in Makefile.am. For example, I also have a plan
to replace fc-cache with a shell script that will run any file executable file
in ''$(bindir)/fc-cache.d/''. And then install the actual
binary of fc-cache as
''$(bindir)/fc-cache.d/fc-cache-$(ARCH)''. This way, on
multi-arch machines,
fc-cache which will do the right thing, which is generating caches for both
archs.
- The configure checks may be a bit slow.
- The downside of this scheme is that it''s autotools-based. But
then
again, people compiling using other tools already have to define
FC_ARCHITECTURE to something. They can keep doing that.
Unless someone shouts, I think I''m going to implement the configure
scheme,
ship the other generated files, and get rid of CC_FOR_BUILD stuff.
behdad
Hi, Nice to see some movement fontconfig-side. 1. please do not create ''$(bindir)/fc-cache.d/'' monstruosities. Use /usr/lib???/fontconfig for that as per FHS 2. please consider making fontconfig depend on an external provider of unicode tables & adobe glyph lists. Fontconfig should really not keep a private copy of those, that makes full-distro updating hard. 3. please consider moving the built-in fontconfig files from /etc/conf.avail to /usr/share/fontconfig/conf.avail as per FHS 4. please consider installing the fontconfig DTD in /usr/share/xml as per FHS (and register it in system xml catalogs) 5. please consider adding an heuristic like the one used by MS in WPF to compute cleaned-up font & face names for non-WWS fonts (sending my rfe list since it''s getting closer to christmas) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20091118/5fae430c/attachment.pgp
Wow, quite a list! Ok, given the current situation (broken 2.7.3, need to get 2.8.0 out with the new cache format), lets get 2.8.0 out today with no further changes such that we can push it to stable distros as an update to 2.7 and start the 2.9 cycle, aim for 2.10 in January. Comments below: On 11/18/2009 11:32 AM, Nicolas Mailhot wrote:> 1. please do not create ''$(bindir)/fc-cache.d/'' monstruosities. > Use /usr/lib???/fontconfig for that as per FHSRight, libexec sounds right.> 2. please consider making fontconfig depend on an external provider of > unicode tables&We only use case mapping. Linking to glib/icu just for that is out of question right now. But is in my longterm plan when I either write my own unicode character database library or make icu''s lightweight and usable.> adobe glyph lists.We don''t use it. The file was in git, I removed it earlier today. We just use the zapfdingbats.txt. I assume because FreeType doesn''t handle that?> Fontconfig should really not keep a > private copy of those, that makes full-distro updating hard.Tell me about it... Still have to update the stack to Unicode 5.2.> 3. please consider moving the built-in fontconfig files > from /etc/conf.avail to /usr/share/fontconfig/conf.avail as per FHSRight. Will do for 2.10. I don''t see any backward compat issues.> 4. please consider installing the fontconfig DTD in /usr/share/xml as > per FHS (and register it in system xml catalogs)Sure. Can you point me to the Makefile.am magic for that? Plus, I need to make a decision re: https://bugs.freedesktop.org/show_bug.cgi?id=1281> 5. please consider adding an heuristic like the one used by MS in WPF to > compute cleaned-up font& face names for non-WWS fontsI''ll do. But it''s really touchy. I need to go back and read the WWS paper again.> (sending my rfe list since it''s getting closer to christmas)Good timing. behdad
Behdad Esfahbod wrote:> #define FC_ARCHITECTURE (\ > CHECK_ARCH("x86", 4,1,4,4) : \ > CHECK_ARCH("x86-64", 8,1,4,8) : \ > "unknown" )On a possibly-related sidenote (yey for thread hijacking!), I wonder if this macro is responsible for another minor issue: With the armel platform, I get cache files like the following: 089dead882dea3570ffc31a9898cfb69-mipsel.cache-2 While it''s really cool to see a real-world hash containing 0xDEAD, the architecture is marked as mipsel. In most situations this will not be a problem, but there does seem to be a bad assumption made somewhere. This is fontconfig-2.6.0, so things may have moved along. --Pat
On 11/18/2009 12:12 PM, Pat Suwalski wrote:> Behdad Esfahbod wrote: >> #define FC_ARCHITECTURE (\ >> CHECK_ARCH("x86", 4,1,4,4) : \ >> CHECK_ARCH("x86-64", 8,1,4,8) : \ >> "unknown" ) > > On a possibly-related sidenote (yey for thread hijacking!), I wonder if > this macro is responsible for another minor issue: > > With the armel platform, I get cache files like the following: > > 089dead882dea3570ffc31a9898cfb69-mipsel.cache-2 > > While it''s really cool to see a real-world hash containing 0xDEAD, the > architecture is marked as mipsel. In most situations this will not be a > problem, but there does seem to be a bad assumption made somewhere. > > This is fontconfig-2.6.0, so things may have moved along.Check fontconfig/fc-arch/fcarch.tmpl.h. It just means that armel and mipsel have the same signature (which is hardly surprising). If you have a better name for the platform, toss it NOW and I''ll change it in 2.8 (since the cache version is changed). It''s not a big deal. And, you were not cross-compiling, right? behdad> --Pat >
Behdad Esfahbod wrote:> Check fontconfig/fc-arch/fcarch.tmpl.h. It just means that armel and > mipsel have the same signature (which is hardly surprising). If you > have a better name for the platform, toss it NOW and I''ll change it in > 2.8 (since the cache version is changed). It''s not a big deal.I''ve given it a few minutes of thought and can''t think of a better name. I would hate to give it some combined name only to find that any number of other architectures have the same signature. But it''s good to know that it''s an issue of naming as opposed to being erroneously detected.> And, you were not cross-compiling, right?No, not cross-compiling. Native compilation is the way to go, IMO. --Pat
> Check fontconfig/fc-arch/fcarch.tmpl.h. ?It just means that armel and mipsel > have the same signature (which is hardly surprising).Even 32-bit x86 Windows has the same;)>?If you have a better name for the platform, toss it NOWJust use a hash code of the properties of the architecture? --tml
On 11/18/2009 01:24 PM, Tor Lillqvist wrote:>> Check fontconfig/fc-arch/fcarch.tmpl.h. It just means that armel and mipsel >> have the same signature (which is hardly surprising). > > Even 32-bit x86 Windows has the same;)I just checked the signature and the only difference with x86 is that the mipsel one has a 8-byte alignment for double whereas x86 has 4byte alignment. That''s quite unfortunate though, since this struct is public. Means that fontconfig binaries can''t be shared between gcc and MSVC :(. The relevant gcc option is: -malign-double -mno-align-double Control whether GCC aligns "double", "long double", and "long long" variables on a two word boundary or a one word boundary. Aligning "double" variables on a two word boundary will produce code that runs somewhat faster on a Pentium at the expense of more memory. On x86-64, -malign-double is enabled by default. Warning: if you use the -malign-double switch, structures containing the above types will be aligned differently than the published application binary interface specifications for the 386 and will not be binary compatible with structures in code compiled without that switch. I checked all the signatures. They all boil down to three properties: - Endian-ness - Long-size (ie. 32bit vs 64bit) - For 32bit systems, the double alignment So, there''s a total of 6 different architectures. In fact, ppc64 and sparc64 there are dupes right now. Lets name them this way: x86: le32n mipsel: le32w x86-64: le64 m68k: be32n ppc: be32w ppc64: le64 How does that sound?>> If you have a better name for the platform, toss it NOW > > Just use a hash code of the properties of the architecture?I thought about that. It makes the cache file names less intuitive for no particular benefit. Plus, there''s a good reason to not rely on hashes: the properties we check for may change in the future and that would change the hash every time. behdad> --tml >
> That''s quite unfortunate though, since this struct is public. >?Means that fontconfig binaries can''t be shared between gcc and MSVC :(.Sure they can. gcc for Windows follows MSVC alignment rules.> They all boil down to three properties > ?- Endian-ness > ?- Long-size (ie. 32bit vs 64bit) > ?- For 32bit systems, the double alignmentBut not pointer size? (Which differs from "long" size on 64-bit Windows.) --tml
On 11/18/2009 02:11 PM, Tor Lillqvist wrote:>> That''s quite unfortunate though, since this struct is public. >> Means that fontconfig binaries can''t be shared between gcc and MSVC :(. > > Sure they can. gcc for Windows follows MSVC alignment rules. > >> They all boil down to three properties >> - Endian-ness >> - Long-size (ie. 32bit vs 64bit) >> - For 32bit systems, the double alignment > > But not pointer size? (Which differs from "long" size on 64-bit Windows.)Then we don''t have any signature for that. All the signatures I have pointer sizes equal to long size. What''s the 64-bit Windows pointer size? It would be best if you give it a try and give me the signature in fact. behdad> --tml >
> What''s the 64-bit Windows pointer size?Well, d''oh, 64 bits;)> It would be best if you give it a try and give me the signature in fact.Will do. --tml
>>>>> "N" == Nicolas Mailhot <nicolas.mailhot at laposte.net> writes:Most of these suggestions are spot on, but: N> 3. please consider moving the built-in fontconfig files from N> /etc/conf.avail to /usr/share/fontconfig/conf.avail as per FHS I''m not convinced that they should move; they are end-user editable config files, symlinks from /etc to /usr are not always welcome, keeping one''s /etc/fonts in a scm works better, (and I''ve managed to forget the other argument or two I wanted to make.) I think Keith was right to put all of the fontconfig configuration together in /etc/fonts. N> 4. please consider installing the fontconfig DTD in /usr/share/xml N> as per FHS (and register it in system xml catalogs) If so, please do this in addition to /etc/fonts/fonts.dtd, not instead of. -JimC -- James Cloos <cloos at jhcloos.com> OpenPGP: 1024D/ED7DAEA6
Le samedi 21 novembre 2009 ? 18:02 -0500, James Cloos a ?crit :> >>>>> "N" == Nicolas Mailhot <nicolas.mailhot at laposte.net> writes: > > Most of these suggestions are spot on, but: > > N> 3. please consider moving the built-in fontconfig files from > N> /etc/conf.avail to /usr/share/fontconfig/conf.avail as per FHS > > I''m not convinced that they should move; they are end-user editable > config files,The files shipped with fontconfig are not user editable, if a user starts editing one without keeping a copy of the original file he is going to get into trouble (also letting users edit them directly asks for no end of ugly conflicts with package managers) Users should be encouraged to : 1. disable the config files they do not like by replacing the symlink in /etc/fonts/conf.d/ by an empty file (just removing the symlink will not prevent its re-creation at next package update) 2. create they own variant directly in conf.d under a separate name If the user wants to write a different config file, but disable it by default, he can either rename his file in /etc/fonts/conf.d/foo.conf to /etc/fonts/conf.d/foo.conf.dud or we can keep a /etc/fonts/conf.avail for this purpose (actual user-managed config files, not reference upstream template data he should never touch)> N> 4. please consider installing the fontconfig DTD in /usr/share/xml > N> as per FHS (and register it in system xml catalogs) > > If so, please do this in addition to /etc/fonts/fonts.dtd, not instead of.Isn''t that a receipe for de-sync? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20091122/73c9d528/attachment.pgp
On 11/21/2009 06:02 PM, James Cloos wrote:>>>>>> "N" == Nicolas Mailhot<nicolas.mailhot at laposte.net> writes: > > Most of these suggestions are spot on, but: > > N> 3. please consider moving the built-in fontconfig files from > N> /etc/conf.avail to /usr/share/fontconfig/conf.avail as per FHS > > I''m not convinced that they should move; they are end-user editable > config files, symlinks from /etc to /usr are not always welcome, > keeping one''s /etc/fonts in a scm works better, (and I''ve managed > to forget the other argument or two I wanted to make.) > > I think Keith was right to put all of the fontconfig configuration > together in /etc/fonts.Yes and no. I agree with what Nicolas said in his reply. In general the problem with the snippets in conf.avail is that it''s not clear how they are supposed to be used. I suggest we take Nicolas''s recommendations and write them out in conf.d/README. Nicolas, care to submit a patch?> N> 4. please consider installing the fontconfig DTD in /usr/share/xml > N> as per FHS (and register it in system xml catalogs) > > If so, please do this in addition to /etc/fonts/fonts.dtd, not instead of.I agree. On 11/21/2009 11:09 PM, Nicolas Mailhot wrote: > Isn''t that a receipe for de-sync? Nah, why? Neither file is supposed to be modified. behdad