> On Fri, 25 May 2001 10:39:14 + (GMT), Martin Hollmichel
><[EMAIL PROTECTED]> said:
> really multiplatform. And I think at the moment the autotools don't
> want/can to support native non Unix platforms.
For my own needs, I've written a tool, `am2msdev', which creates MS
Dev Studio p
> Before I address your points, or at least the ones I plan to address,
> I thought first I would write my own critique of the auto tools.
> While I do think that these tools have deep problems, I also think you
> largely avoided mentioning them.
Yes, you're right, I avoided that. if you're looki
> "Axel" == Axel Thimm <[EMAIL PROTECTED]> writes:
Axel> The request was for experience in making the
Axel> autoconf/automake/libtool set work with Borland C++.
Doing this would be fine from the automake perspective.
If the compiler is too different from a Unix compiler it might be
easiest t
On Thu, May 24, 2001 at 05:46:49AM -0400, Thomas E. Dickey wrote:
> On Wed, 23 May 2001, Axel Thimm wrote:
> > > may be there are some hints whether people have already tried with
> > > borland compilers.
> > Let's hope they are reading this list and will step forward to discuss it ;)
> sure - B
On Wed, 23 May 2001, Axel Thimm wrote:
> > [...] may be there are some hints whether people have already tried with
> > borland compilers.
>
> Let's hope they are reading this list and will step forward to discuss it ;)
sure - Borland C is much faster, and checks for errors that gcc doesn't
both
On Wed, May 23, 2001 at 01:43:59PM +0200, Guido Draheim wrote:
> I would recommended to use atleast gmake and (ba)sh which are both available
> for win/dos, and having the complete gnu fileutils is not a bad idea either.
Yes, as a first step I was considering cygwin as a solid basis for sh/perl
e
> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> Make config.status put all the configuration information into a
Peter> single makefile and have all the other makefiles include that
Peter> one. It's saved me many boring waits.
That's an interesting idea. We could even imple
Martin Hollmichel writes:
> * changing a autotool file, then waiting for configure to write 1200
> makefiles.
Make config.status put all the configuration information into a single
makefile and have all the other makefiles include that one. It's saved me
many boring waits.
--
Peter Eisentraut
Tom Tromey wrote:
>
> > "Rasmus" == Rasmus Tamstorf <[EMAIL PROTECTED]> writes:
>
> Rasmus> I think the issue is that with autoconf you setup your
> Rasmus> compiler flags (debug / optimized etc) for the entire build
> Rasmus> tree when you run ./configure. However, while developing you
> Ra
On 23 May 2001, Tom Tromey wrote:
> > "Rasmus" == Rasmus Tamstorf <[EMAIL PROTECTED]> writes:
>
> Rasmus> I think the issue is that with autoconf you setup your
> Rasmus> compiler flags (debug / optimized etc) for the entire build
> Rasmus> tree when you run ./configure. However, while devel
> "Rasmus" == Rasmus Tamstorf <[EMAIL PROTECTED]> writes:
Rasmus> I think the issue is that with autoconf you setup your
Rasmus> compiler flags (debug / optimized etc) for the entire build
Rasmus> tree when you run ./configure. However, while developing you
Rasmus> may want 90% to be optimize
On 23 May 2001, Tom Tromey wrote:
> On to your complaints.
>
> Martin> * Mixing up debug and non debug build, do both causes double
> Martin> compile time, double diskspace and x-time more RAM for the
> Martin> debugger. Imagine to need 10 GB for Openoffice debug build and
> Martin> more than 2G
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
Harlan> While (IMO) it "did better" than autoconf for quite a few
Harlan> years, I bailed on it several years ago because it was not
Harlan> suitable (at that time) for srcdir != builddir, and that was
Harlan> something I needed Badly. T
> I'm unaware of any. There is Metaconf (the Perl thing), but in my
> experience it isn't deeply better than autoconf. It is different, but
> less well documented and with a smaller user community.
I was the metaconfig maintainer for several years.
While (IMO) it "did better" than autoconf for
> "Guido" == Guido Draheim <[EMAIL PROTECTED]> writes:
Guido> alternatives? I mean free, documented, mature, easy
Guido> alternatives to be seen?
I'm unaware of any. There is Metaconf (the Perl thing), but in my
experience it isn't deeply better than autoconf. It is different, but
less wel
> "Martin" == Martin Hollmichel <[EMAIL PROTECTED]> writes:
Before I address your points, or at least the ones I plan to address,
I thought first I would write my own critique of the auto tools.
While I do think that these tools have deep problems, I also think you
largely avoided mentioning
Martin Hollmichel wrote:
>
> Hi all,
>
> I think the great misunderstanding is that the autotools are
> not targeting real multiplatform development, but Unix centric
> distribution of (GNU) OpenSource Software.
>
> To do real multiplatform, multitools development the autotools
> are difficult
Martin Hollmichel wrote:
>
> Hi all,
>
> I think the great misunderstanding is that the autotools are
> not targeting real multiplatform development, but Unix centric
> distribution of (GNU) OpenSource Software.
well, they are not restricted to the *but* IMHO. They are
just not 100% ready-made
This is not restricted to borland compilers, there are quite
some C-compilers on unix-systems that quite some people like
to see supported, however most of the autotools developers
do live in a quite gnu'ish/gcc'ish environment, and every now
and then, a gmake'ish/gcc pecularity slips in that wil
sorry for the excessive addressing, but this topic touches all auto-tools.
I am in the process of convincing some people to move their Borland based
source code development to proprietary free models. As you may guess, this is
an extremly difficult task, requiring more pedagogical than technical
20 matches
Mail list logo
