On May 27, 2005, at 7:36 AM, Axel Wei� wrote:
James Berry wrote:
Am I missing something? I do check for wchar.h.
Hi James,
yes, I overlooked it: you do check it in configure.ac through the
symbol
AC_CHECK_HEADERS. But this means that we require wchar.h
unconditionally on every platform. Are you sure that this header
always
exists?
No, I'm not sure that it always exists. We don't currently enable the
iconv transcoder, however, if it does not. The iconv transcoder
doesn't seem to be able to live without what it provides.
So: if we find a platform for which an alternative implementation
would work without wchar.h we can relax that check and provide
another workaround. Until then, iconv requires wchar.h.
Another (minor) issue: now make is called in the src directory,
once and
for all subdirectories. This causes all object files be produced in
the
src directoy (because automake knows it not better;). This behaviour
was originally not intended by the authors of automake, who instead
want to have one Makefile.am in each subdir, and make be called
recursively.
Besides the danger of accidentially having object files be
overwritten,
if they have identical names and their sources in different subdirs,
it's just unaesthetic to have all the object files lying around in an
unstructured way. Don't you agree, that it would be much nicer to have
recursive make again and one Makefile.am in each subdir?
I've gone back and forth on this. There are very good arguments,
however, for using a single monolithic make rather than recursive make:
http://www.gnu.org/software/automake/manual/html_mono/
automake.html#Alternative
http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html
Taken in by those arguments, I've gone for the monolithic make in
large part. There are separate makefiles for obj, src, tests.
I threw a switch last night that causes all the .o files to end up at
the root of the make (src, for instance) rather than alongside their
src files. After continually stumbing over the .o files in the source
directory, I decided this was better behavior. There are no conflicts
that I know of yet, and the nice part is that there's not a lot of
other code in src.
Feedback on these decisions is welcome.
Cheers,
Axel
--
Humboldt-Universit�t zu Berlin
Institut f�r Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Wei�
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]