Build and Runtime Errors with MFTrace 1.2.3
There are (at least) two issues with the CVS contents of MFTrace 1.2.3:
(1) sh autogen.sh produces a mftrace.spec file that references two .pyo
files that make will not create.
(2) After building and installing mftrace-1.2.3-1.i586.rpm, mftrace
--version fails, because of two UnindentErrors in the main script.
The attached patch tries to fix these two problems.
Take care
Index: mftrace/mftrace.spec.in
===
--- mftrace/mftrace.spec.in (Revision 1)
+++ mftrace/mftrace.spec.in (Revision 2)
@@ -42,10 +42,8 @@
%{_prefix}/bin/mftrace
%{_mandir}/man1/mftrace.1.gz
%{_datadir}/mftrace/afm.pyc
-%{_datadir}/mftrace/afm.pyo
%{_datadir}/mftrace/afm.py
%{_datadir}/mftrace/tfm.pyc
-%{_datadir}/mftrace/tfm.pyo
%{_datadir}/mftrace/tfm.py
%doc README.txt
Index: mftrace/mftrace.py
===
--- mftrace/mftrace.py (Revision 1)
+++ mftrace/mftrace.py (Revision 2)
@@ -504,7 +504,7 @@
# for single glyph testing.
# glyphs = []
for a in glyphs:
- if encoding[a] == .notavail:
+if encoding[a] == .notavail:
continue
valid = metric.has_char (a)
if not valid:
@@ -783,9 +783,9 @@
return outname
def make_outputs (fontname, formats, encoding):
-
- run pfaedit to convert to other formats
-
+
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make web fails for LilyPond 2.8.0/2.9.0 source drop [Also] Re: Futile attempts to build LilyPond 2.8.0
R. Mattes rm at mh-freiburg.de writes: Ok, i found the bug. It looks like this is triggered by using guile-1.6.n instead of guile-1.8 - this also explains why Andreas' build failed. Confirmed. After updating OpenSUSE 10.0 with guile-1.8.0, all is well again. make all web runs to completion with both the LilyPond 2.8.1 source drop and the 2.9.1 CVS contents. Thanks, Ralf, for digging into this. Take care ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compiling CVS 2.7.16 with g++ 3.3.4
Am Mittwoch, 9. November 2005 10:36 schrieb Han-Wen Nienhuys: I don't understand this patch. Why doesn't str need a cast? What's the difference between reinterpret_castconst shar* and (const char*) After updating to OpenSUSE 10.0 with g++ 4.0.2 the problem is gone. The CVS code compiles without the patch. Case closed. Cheers ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.5: isinf
On Friday 03 December 2004 19:11, Christian Hitz wrote: The proposed solution is to use math.h instead of cmath. In my patch I introduce a new define MACOS_X that controls this. With this patch applied I compiled the latest CVS this afternoon. Compiles fine on GNU/Linux as well. Sure, it's a hack, but that's what one gets when one uses the preprocessor. ;-) Andreas ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
LilyPond 2.5: isinf macro/function/template
Hello list, I have tried to analyze the isinf issue, resulting from my #include cleanup patch for LilyPond 2.5, and want to submit the following results, created with gcc/g++/libc/libstdc++ 3.3.4 on SuSE Linux 9.2. If you look at the LilyPond C++ sources you find that the issue with isinf seems to have been addressed before. Module flower/libc-extension looks for a /macro/ isinf and if such a thing does not exist /and/ if the initial configuration finds no isinf function in the system libraries (!HAVE_ISINF), a local version of int isinf(double) is defined. (I have no idea whether this situation ever arises.) Module lily/liy-guile explicitly has a MacOS fix (with an additional FIXME), because source-file.hh somehow pulls in cmath, thus overriding any isinf macro definition. Of course, after my change in lily/lily-guile.cc (s/math.h/cmath/ et al.), this fix does no longer work. The attached archive contains two source files in C and C++ calling isinf in various incantations. The C version uses math.h as the interface and in one situation I can bring gcc to at least issue a warning regarding an implicit declaration of function isinf after the line #undef isinf. The C++ version uses cmath as the interface and calls isinf (before and after #undef isinf), ::isinf, and std::isinf without complaint. So, on this GNU/Linux system, there is no real problem with isinf, either as a macro, a function, or a template. According to man isinf on my configuration, isinf/isnan/finite are functions (sic!) conforming to BSD 4.3. It further states that C99 provides additional macros (!), such as the type-independent fpclassify(), isinf(), and isnan() (and with option --std=c99 plus #undef isinf in the code, gcc 3.3.4 issues the above-mentioned warning). IIRC, MacOS X is based upon BSD, so it is unclear to me, how this BSD-conforming function/macro should be unavailable for use in C++ programs. My best guess is that BSD /only/ has the isinf /macro/ in math.h and no underlying isinf system /function/ reachable through a different interface (like said /template function/ in cmath on Linux) /and/ cmath #undefines exactly this macro. Hopefully, some member with MacOS eXperience can find a compliant solution to the problem. Take care -- Andreas Scherer Saarstraße 76, 52062 Aachen, Germany http://people.freenet.net/andreas.scherer isinf.tar.gz Description: application/tgz ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.5: isinf macro/function/template
On Sunday 28 November 2004 16:25, Christian Hitz wrote: I got lilypond 2.5.2 to compile by doing the following things: - set _GLIBCPP_USE_C99 before #include cmath in the files that use isinf/isnan - replace each occurrence of isinf/isnan with std::isinf/std::isnan I don't know if this breaks compilation on linux. The first step is (at least on /this/ GNU/Linux) already done, so the templated versions of the C99 functions do exist after including cmath. Plus, gcc/g++ on GNU/Linux readily (too readily?!) puts this stuff in the std:: namespace plus exports it to the global namespace (as shown in my C++ example code; maybe one would have to use a commandline option to force some specific behaviour). So, I don't think your approach would (in the short run) break anything for Linux. However, at least the _GLIBCPP_USE_C99 macro setting should be dealt with by the auto-configure setup and be put into some central configuration. At least, there seems to be some light at the end of the tunnel. :-) Andreas ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond C/C++ #include cleanup
On Friday 19 November 2004 14:52, Han-Wen Nienhuys wrote: I've added the Doxygen file to CVS. I'm willing to add doxygen rules to the makefile, if someone writes them. Unfortunately, I'm not proficient with 'autoconf', so I can't provide a working solution right now. But here's what I've got so far and my ideas about how to fill the gaps: (1) Move 'Doxyfile' to 'Documentation/Doxyfile.in' and apply the attached patch; it introduces variables @PACKAGE_NAME@, @TOPLEVEL_VERSION@, and @HAVE_DOT@ at the appropriate locations and it makes 'doxygen' look for input starting at directory '..'. (2) Let the toplevel 'configure.in' check for 'doxygen' and 'dot': STEPMAKE_PROGS(DOXYGEN, doxygen, OPTIONAL, 1.3.8) STEPMAKE_PROGS(DOT, dot, OPTIONAL, 1.16) and set the variable HAVE_DOT to 'YES' if 'dot' is present, otherwise to 'NO'. (3) [I failed to achieve this step; all I managed was to replace PACKAGE_NAME, but not the other two variables] Create 'Documentation/Doxyfile' from 'Documentation/Doxyfile.in' by replacing the @-variables with their current contents, e.g., 'LilyPond', '2.5.0hwn1', and 'YES' resp. 'NO'. (4) In the GNUmakefile for directory Documentation run the command line doxygen Doxyfile, iff DOXYGEN is set in (2). There is no other dependency necessary as soon as the 'Doxyfile' is installed. DOT will be triggered by DOXYGEN only when HAVE_DOT is 'YES'. I'm sure it is not hard to do this, but as I said above, I've never used 'autoconf' and even after some trial, all I got were errors. Andreas Doxyfile.patch.gz Description: GNU Zip compressed data ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
LilyPond C/C++ #include cleanup
Hello list, Has anyone considered to apply Doxygen to the LilyPond sources? I'm aware that the internal comments are not doxygen'erated, however, Doxygen is capable to analyze plain C/C++ codes and to generate at least rudimentary documentation in various output formats. One of the major advantages is the creation of graphical displays of specific aspects of a bundle of source codes, e.g., class hierarchy, class graphs, and include/included-by graphs. With the tool doxywizard (1.3.9) I have created a rudimentary Doxyfile and run Doxygen over the CVS content of current LilyPond. This definition file is attached to this submission for those who would like to apply Doxygen themselves. Now, when I click through the HTML documentation and look at the images of the include graphs, I find that many #include directives are redundant, i.e., define transitive connections between header a/o source files (plus at least one cyclic dependency between flower/include/string.hh and flower/include/international.hh). It is common knowledge (John Lakos and other experts come to mind) that the #include hierarchy can be an important backbone of a C/C++ software system as well as an elementary entry point to understanding such a system. If there is interest in this group for such an improvement of the C/C++ sources of LilyPond, I would volunteer to make the necessary modifications, i.e., to remove the superfluous #include directives, while guaranteeing the correct compilability of the system. Any comments? Cheers, Andreas Doxyfile.gz Description: GNU Zip compressed data ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
