Re: Compilation on FreeBSD

[Edward Sanford Sutton]

On Tuesday 01 March 2005 00:19, you wrote:
> Edward Sanford Sutton napsal(a):
> >   The following should hint you as to how to modify the Makefile in the
> > ports directory. I haven't had time to try to push such changes into
> > ports. The port maintainer has not responded to anything in a long time
> > that I am aware of.
> >   The lilypond-devel port (2.3.2?) is currently broken due to that and a
> > couple other issues, but can be pushed up to about 2.3.20 before a
> > solution has to be worked out since makeinfo (i think that was the
> > culprit) is not up to date enough to proceed anymore. Either it has to be
> > updated within the
>
> I know, I try contact maintainer at first time :-(
>
> > base system (unless there were recent changes to it in stable or current
> > that i am unaware of) or maybe that tools collection needs to become a
> > port. Correction: apparently the devel port is now no longer present in
> > my ports tree. I wish i knew the who or when that made that happen. Seems
> > 2.2.2 is also now marked as broken.
>
> I have installed lilypond 2.2.2 on my system - i find another patch on
> internet (author Tim Allman):
>
> Commented out the BROKEN line in Makefile.

You can also use
make -DTRYBROKEN
to define TRYBROKEN which will cause make to continue with building a port 
that is marked as broken.

> ====
> In file work/lilypond-2.2.2/lily/includable-lexer.cc
> Inserted before line 30 the line:
> #define HAVE_FLEXLEXER_YY_CURRENT_BUFFER
> This turns off some code which fails to compile.

Usually code is in place. Was this code unnecessary, or just turned off 
because it was in the way of a successful compile?

> ====
> In file work/lilypond-2.2.2/lily/out/FlexLexer.h
> Changed several instances of std::std:: to std::
> Changed several instances of std:std:: to std::
>
>
> -------------------------------------------------------------------
>
>
>
> But - I trying upgrade port in ports tree to version 2.4.4

  That version is beyond 2.3.20 and will have the makeinfo issues if I 
remember right. I think the new lilypond dependency was makeinfo 4.7. Either 
texinfo needs to be updated in the base system or a port for it needs to be 
introduced to get makeinfo up to date. The other option required modifying 
lilypond files, but that seems unnecessarily ugly; it would be undoing work 
to modernize lilypond and I think that meeting the dependencies is much 
better than trying to modify lilypond to fit older dependencies. 
  Modifications seem to make it harder to maintain too; 2.3.2 had always 
failed right from the ports tree for all I've seen because a patch didn't 
quite match a file right. 
  If you have not done so, I would suggest that you pull up a copy of the old 
devel port to reference to also; 2.3 should have been closer to 2.4 than 2.2 
was.

> Thanks Jan, his patch works (last version of his patch isn't in this
> list, hence I send its copy):

  Did the patch work without interfering with other systems too? The GCC 
version control was the only way I found to make lilypond compile without 
other patching. It should have created a fully functional lilypond. Maybe 
patches are a better way to do it. I think the best patches are the ones that 
go into an original project rather than get applied to one distribution.

> Index: lily-guile.cc
> ===================================================================
> RCS file: /cvsroot/lilypond/lilypond/lily/lily-guile.cc,v
> retrieving revision 1.180
> retrieving revision 1.180.2.2
> diff -p -u -p -u -r1.180 -r1.180.2.2
> --- lily-guile.cc     7 Oct 2004 19:39:50 -0000       1.180
> +++ lily-guile.cc     28 Feb 2005 11:24:04 -0000      1.180.2.2
> @@ -836,6 +836,6 @@ LY_DEFINE (ly_gettext, "ly:gettext",
>   {
>     SCM_ASSERT_TYPE (scm_is_string (string), string, SCM_ARG1,
>                  __FUNCTION__, "string");
> -  return scm_makfrom0str (gettext (scm_i_string_chars (string)));
> +  return scm_makfrom0str (_ (scm_i_string_chars (string)).to_str0 ());
>   }
>
>
>
> Zbynek