Hi Gary,
* Gary V. Vaughan wrote on Fri, Feb 03, 2006 at 01:06:40PM CET:
> Ralf Wildenhues wrote:
> >
> > - Makefile.am rules somewhere use GNU make 3.80 features. I have
> > encountered many difficulties preventing autotools reruns on other
> > systems, and am quite fed up with hunting these
On Fri, 3 Feb 2006, Ralf Wildenhues wrote:
It means that LT_WITH_LTDL in configure.ac that mentions neither
LTDL_CONVENIENCE nor LTDL_INSTALLABLE doesn't build libltdl at all.
I have a start to a fix for this.
Well, so is that really a bug? AFAIK the 1.5 docs require you to use
AC_LIB_LTDL, _
* Gary V. Vaughan wrote on Fri, Feb 03, 2006 at 03:43:11PM CET:
>
> [Is the personal Cc: okay? The list lag is so long that I've gotten into
> the habit of Cc:ing you back in so you don't have to wait half a day to
> get this.]
Yes, surely. There was one point in time where I fixed my gnu.org
Hi Gary,
* Gary V. Vaughan wrote on Fri, Feb 03, 2006 at 01:06:40PM CET:
> Ralf Wildenhues wrote:
> >
> > However, I have absolutely no problem with delaying the application of
> > the per-deplibs-flags patch to shortly after 2.0.0 or 2.0.2. Although
> > we should still commit both the `-static'
Ralf Wildenhues wrote:
> Hi Gary,
Hallo Ralf!
> Gary V. Vaughan writes:
>> Now is the time to branch! Either a feature branch for developing the
>> per-deplib feature for merging after 2.0, or else a 2.0 branch that we
>> can keep stable.
>
> No way, without me. I outright refuse to maintain a
Ralf Wildenhues wrote:
> Hi Gary,
Hallo Ralf!
[Is the personal Cc: okay? The list lag is so long that I've gotten into
the habit of Cc:ing you back in so you don't have to wait half a day to
get this.]
> > > > * LT_WITH_LTDL should build libltdl by default; currently
> > > >nothing
On Thu, 2 Feb 2006, Gary V. Vaughan wrote:
According to: http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap, the
three remaining release blockers for 2.0 are:
* libtool.m4 macro ordering/requirement audit. pending
* LT_WITH_LTDL should build libltdl by default; currently
nothing happens
Hi Gary,
Gary V. Vaughan writes:
>
> Is this patch really necessary for 2.0?
No.
> I think that introducing so
> much code churn in to libtool at this stage is going to bring yet more
> release delays. Surely the feature is useful and desireable, but I
> really *really* want to avoid more delay
On Sat, Feb 26, 2000 at 09:48:19PM -0300, Alexandre Oliva wrote:
> On Feb 26, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
>
> > making it relatively similar to bourne shell wouldn't hurt since that
> > is already a known quantity, and will be easier for maintainers to get
> > to grips with
On Feb 26, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> making it relatively similar to bourne shell wouldn't hurt since that
> is already a known quantity, and will be easier for maintainers to get
> to grips with
In fact, if we could keep it fully compatible with (a subset of)
Bourne s
On Sat, Feb 26, 2000 at 11:29:23AM -0500, Ezra Peisach wrote:
>
>
> Ok - I'm game. Do you have any ground rules regarding the syntax of "u"?
Well, the higher level we can make it, the better. On the other hand,
making it relatively similar to bourne shell wouldn't hurt since that
is already a
Ok - I'm game. Do you have any ground rules regarding the syntax of "u"?
For instance, will you support functions, cleanup handlers, and system
builtins? I am assuming basic conditionals, loops, etc.
In looking at the simple compile example, you need to be able to
lock/unlock a file, create s
On Thu, Feb 24, 2000 at 03:54:58AM -0500, Ezra Peisach wrote:
>
> I too am concerned with performance with libtool. I tried slipping
> libtool into a complicated package and the build time went from 1'20"
> to 2'00". Not the fastest of machines, but
And as more features pile in, it will get
13 matches
Mail list logo
