Re: Auto-tools & Win32 & Borland C++ Builder

[Guido Draheim]

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 will break
the next time another tool'ed environment is seen. 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. On this basis, look for any problems
related to assumptions about the gcc, and e-mail the resp.
people that are guilty ;-) Possibly, install a gcc-distribution
like cygwin32 or mingw32 (http://libsdl.org/Xmingw32), start
a normal gcc/automake setup, and run "sh configure CC=bcc32".
I guess it will extremly stress your technical skills to
find the bits that assume CC=gcc and a unix-filesystem, and 
furthermore I guess that such work will be very welcome as 
it will help supporting non-gcc compilers on other unix-platforms 
as well, minus the tricks about filepaths. Make sure to use
the newest autotools, the last months have seen quite some
improvements in supporting cygwin/mingw platforms which will
make things quite a bit easier for you.

sorry for the extreme addressing. however, may be there
are some hints whether people have already tried with
borland compilers. I did lately build an nmake-makefile 
for the free(!!) borland 5.5 compilers (which means commandline 
only). However, for a pure C project, the compiler looks
a bit inferior wrt. to gcc, so I'd switch to gcc anyway,
I don't know about C++... all that I've heard so far, that
people did stop at some point to try to get along with the
non-gcc compiler, since the gcc compiler suite is way good
enough for anything that is needed which is the actual 
reason why bcc-support / msvc-support is not answered in
an FAQ. Starting to use gcc on win/dos, well, again, this 
is more a pedagogical endavour, 

Another scheme is of course the usage of the C++Builder
as a front-end, and use its project-files to generate 
a makefile(.am/.in) that can make it build in environments 
that don't have a borland compiler. Again, you'd have to
change away anything that is non-portable across compiler
sets, so one could start to use gcc's c++ anway, which
again does not need bcc support in the original setup. So
I guess, approaching autotools enthusiasts, it may come
out to the question why you're using borland compiler-chain
anyway as portability is best achieved with the gcc itself.
Again, partly a pedagogical endavour (if not flames) that
should be limited to one mailing-list. Possibly libtool.

oops, got a bit long an winded, cheers, guido

Axel Thimm wrote:
> 
> 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 skills
> (and unfortunately myself is extremly Unix-centric, and I still have to learn
> about Borland's peculiarities).
> 
> Nevertheless I want to give it a try. As a first step I'd have to move the
> configure/build/install infrastructure to auto-tools, then I'd attack the
> compiler non-portability (and by the end of this decade I might get a GNU
> compilant system ...).
> 
> Searching the lists/net nothing helpful came up, but at least there also
> wasn't any evidence of any NoGo-theorems.
> 
> Does anyone have already some experience in working with auto-tools and
> Borland from the command line? How do the maintainers/release managers here
> think about it? Would they be willing to accept patches for supporting
> commercial compilers ;)
> 
> Regards, Axel.
> --
> address@hidden

-- guido                         Edel sei der Mensch, hilfreich und gut
31:GCS/E/S/P C++$++++ ULHS L++w- N++@  d(+-) s+a- h.r(*@)>+++ y++ 5++X-