[Mono-devel-list] [LONG] Any Interest in FreeBSD Patches? Then see attached.
dick at ximian.com
Fri Jul 16 17:30:35 EDT 2004
On Fri, 2004-07-16 at 22:13, John Merryweather Cooper wrote:
> On Fri, 2004-07-16 at 13:28, Dick Porter wrote:
> > > # patch-configure
> > > #####
> > >
> > > The build environment in the FreeBSD Ports system defines two
> > > environment variables: PTHREAD_CFLAGS and PTHREAD_LIBS. The contents
> > > of these two environments vary depending on the FreeBSD version,
> > How does this patch impact FreeBSD builders of the tarball? I'm
> > assuming PTHREAD_CFLAGS and PTHREAD_LIBS won't be set automatically for
> > them. Is it possible to have a set of probably-correct defaults, and
> > let the ports build override them?
> I'm unclear about your reference to "FreeBSD builders of the tarball."
I mean someone running FreeBSD that happens to download the tarball from
the mono web site, and tries to build it themselves.
> These values can always be recovered from /usr/ports/Mk/bsd.port.mk.
> Note that only the first (-STABLE) and last (-CURRENT) choices are
> maintained in for ports (such as lang/mono) in the ports tree, but there
> are still plenty of people running older -CURRENTs. However, nobody has
> been able to get lang/mono to run on the non-KSE -CURRENTs, so it's a
> pretty dead choice.
> Since there's considerable development energy on threads in -CURRENT,
> expect these flags to change "early and often" on -CURRENT.
That doesn't sound like we can do this in configure then. We need to
reach a consensus from the FreeBSD users here: do we just put the ports
options in configure.in?
> > > # patch-ltmain.sh
> > ltmain is a generated file (from libtool.)
> > > # patch-mono_Makefile.in
> > Again, Makefile.in is a generated file, built from Makefile.am. There
> > is no tests directory specified in Makefile.am.
> As a general rule, we try to avoid using automake. So, we take the
> configure scripts and *.in files as we find them and patch them to
> work. There's just too much chaos in the auto[tools] stuff--although
> there is a strong effort to resolve this chaos for FreeBSD, we're not
> there yet.
I think you're going to have to maintain these particular patches
More information about the Mono-devel-list