Ciao Gilles!
At 10.24 27/08/2003 -0500, Gilles Detillieux wrote:
The weekly snapshots have the same problem, as the snapshot script just
does a cvs check-out of the source and archives it, without fixing the
mod times.
I see.
For final releases, Geoff has a script that's supposed to set everythin
Hi Jim,
At 22.39 27/08/2003 -0600, Jim Cole wrote:
FYI - I tried pulling another copy from CVS this morning and was able
to get past the auto-tool versioning issues; however I ran into another
problem during the build. The output is shown below. This problem is
still present in a fresh copy that I
FYI - I tried pulling another copy from CVS this morning and was able
to get past the auto-tool versioning issues; however I ran into another
problem during the build. The output is shown below. This problem is
still present in a fresh copy that I pulled from CVS just a few minutes
ago. Any
Hi guys,
I am happy to announce that I solve most of the problems that my patch
brought into ht://Dig sources before I came to Australia.
Now I can successfully run 'make check' on all of the compile farm's
workstations (except Darwin, where I don't have an account - I used to!).
Here is
According to Gabriele Bartolini:
> I don't know why it was broken, whereas when I did it at commit time it
> worked for me; it's just that before leaving for Australia I had to set up
> many things and I lost all the contents of my hard drive 2 days before
> taking off!!! For sure I forgot to up
At 17.06 24/08/2003 -0600, Jim Cole wrote:
On Sunday, August 24, 2003, at 05:31 AM, Gabriele Bartolini wrote:
Also I put the 'AM_MAINTAINER_MODE' string into the db/configure.in file
which prevented code from be compiled when users did not have autoconf
(at least 2.57), automake and friends inst
On Sunday, August 24, 2003, at 05:31 AM, Gabriele Bartolini wrote:
Also I put the 'AM_MAINTAINER_MODE' string into the db/configure.in
file which prevented code from be compiled when users did not have
autoconf (at least 2.57), automake and friends installed.
No change for me. Running make fails
Ever the impatient one, can I suggest that this patch be backed out
until after 3.2.0b5 is released? Is it providing any *vital*
functionality that couldn't wait until after the release? Weren't we
just about ready for a code freeze?
Sorry about it guys. I had the connection only a few days ago
Greetings all,
Ever the impatient one, can I suggest that this patch be backed out
until after 3.2.0b5 is released? Is it providing any *vital*
functionality that couldn't wait until after the release? Weren't we
just about ready for a code freeze?
If there are still problems with my hacking
My experience on OS X has been that you need the latest version of the
auto* tools if you want to build dynamic shared libraries. In fact,
there is a version of the automake file that comes on Mac OS X (Jaguar)
that has been specially tuned by Apple and that they recommend you use
when buil
Il mer, 2003-07-30 alle 20:39, Jim Cole ha scritto:
> What problem exactly did you run into with the 'db' directory? I did a
> make distclean intending to chase the problem I ran into a little
> further, but then ended up in a state where make fails in the 'db'
> directory due to there being no
On Wednesday, July 30, 2003, at 12:20 PM, Gabriele Bartolini wrote:
That's what I believe too. AFAIK autotools are needed only if you want
to rebuild configure scripts and Makefile.in files. I have not run on
this problem on my laptop (where I generated it all). But ... I came
into this problem
Ciao guys,
I am sorry if the patch is causing problems. But ... with the word
'test' I meant exactly this. Try it and discover some problems.
I don't know if it's still the case now, but in the past the auto*
tools were only needed when you needed to develop/update the Makefiles,
and weren't
According to Jim Cole:
> Hi - As someone already mentioned with regard to their Red Hat install,
> the configuration changes to the 3.2 code base require auto* tools more
> recent than those provided with the distribution. The same is true for
> OS X, which currently provides autoconf 2.52 and a
Hi - As someone already mentioned with regard to their Red Hat install,
the configuration changes to the 3.2 code base require auto* tools more
recent than those provided with the distribution. The same is true for
OS X, which currently provides autoconf 2.52 and automake 1.6.1. It
looks like t
15 matches
Mail list logo
