Hi Peter, thanks for the quick reply.
On 04/27/2012 12:00 PM, Peter Breitenlohner wrote:
> On Fri, 27 Apr 2012, Stefano Lattarini wrote:
>
>>> diff --git a/t/objcxx-demo.sh b/t/objcxx-demo.sh
>>> new file mode 100755
>>> index 0000000..7af089f
>>> --- /dev/null
>>> +++ b/t/objcxx-demo.sh
>>> @@ -0,0 +1,61 @@
>>> +#! /bin/sh
>>>
>>> +# Demo package using Objective C++ and doing distcheck.
>>> +
>>> +required='cc c++'
>>> +. ./defs || Exit 1
>>> +
>>> +cat >> configure.ac << 'END'
>>> +AC_PROG_CC
>>> +AC_PROG_CXX
>>> +AC_PROG_OBJC
>>> +AC_PROG_OBJCXX
>>>
>> Here, we should ensure the test is skipped if any of AC_PROG_OBJC or
>> AC_PROG_OBJCXX is undefined (because the autoconf version being used
>> is too old, i.e., < 2.66 if I'm not mistaken). That can be done in
>> a follow-up patch though.
>
> According to my info (from 2009) and the Autoconf-2.68 NEWS it is < 2.65.
> How to do such a test when Automake already requires 2.68.
>
No, the Automake *build system* needs to be bootstrapped with 2.69 (so
that is a maintainer-only requirement). Automake itself support up to
autoconf 2.62 (and yes, it is quite regularly tested with that).
>>> +AC_CONFIG_HEADERS([config.h])
>>> +AC_OUTPUT
>>> +END
>>> +
>>> +cat > Makefile.am << 'END'
>>> +bin_PROGRAMS = play
>>> +play_SOURCES = play.c playxx.cxx playobjc.m playobjcxx.mm
>>>
>>> +END
>>> +
>>> +cat > play.c << 'END'
>>> +#include <config.h>
>>> +#include <stdio.h>
>>> +int main (void)
>>> +{
>>> + printf("Hello, world! (" PACKAGE_STRING ")\n");
>>> + return 0;
>>> +}
>>> +END
>>> +
>>> +echo '//' >> playxx.cxx
>>> +
>>> +echo '/* */' >> playobjc.m
>>> +
>>> +echo '//' >> playobjcxx.mm
>>> +
>> Rather than having dummy files, I'd like to have files with real content
>> here, to ensure better similarity with real-world usage.
>
> No problem.
>
Thanks.
>> Extra points if you can make the content of the '.m' file valid only as ObjC
>> (not as ObjC++, C, nor C++) and the content of the '.mm' file valid only as
>> ObjC++ (not as ObjC C, nor C++), to ensure the correct compiler is being used
>> based on the file extension.
>
> I'll try, but that might go beyond my knowledge of ObjC/ObjC++.
>
This is no "hard requirement" anyway, just something nice to have.
> I am doing all this for the TeX Live build system that contains two programs
> where the Mac OS X versions use .m and .mm files. Until now the .mm file
> is invoked via a C++ wrapper and put into a separate library libxetexmm.a
> compiled with libxetexmm_a_CXXFLAGS=-ObjC++ -- what a kludge.
>
>> Even more kudos if you can make the all the functions defined in all of
>> 'playxx.cxx', 'playobjc.m' and 'playobjcxx.mm' actually invoked by the
>> 'main()' function.
>
> Should be simple enough with main() in playobjcxx.mm [or the (Obj)C(++)
> functions invoked indirectly via C functions in the respective (Obj)C(++)
> files], as long as you don't require that the program actually runs
>
Why wouldn't it be able to run? (Honest question, I know nothing about
Objective C/C++).
> and does anything useful.
>
Printing a line of output from each of those files would be enough :-)
$ ./play
[Hello C]
[Hello C++]
[Hello ObjC]
[Hello ObjC++]
>> Also, for a better coverage, I'd like to have two more tests (in new files):
>>
>> - one that tests automatic dependency tracking for '.mm' files
>> (t/objcxx-deps.sh)
>>
>> - one that checks the use of global compile flags '$(AM_OBJCXXFLAGS)',
>> per-taget compile flags '$(foo_OBJCXXFLAGS)', that the latter takes
>> precedence on the former, and that user-specified compile flags
>> '$(OBJCXXFLAGS)' take precedence over both
>> (objcxx-flags.sh)
>>
>> Similar tests should also be added for the Objective C case; but that's
>> material
>> for a follow-up patch.
>
> I think part of that could be done by extending existing tests (ext2.sh,
> specflg-dummy.sh, and/or specflg2.sh), the rest by new tests inspired by
> those. Will have a look.
>
Thanks. Sorry if I don't try to write those tests myself, but as I've said,
my knowledge of Objective C/C++ is zero; but I will try to give you as much
feedback as I can.
Regards,
Stefano
