On 7/20/06, Amitha Perera <perera@...> wrote:
> I think you will find some conflicts, but they should be few and
> trivial to change. I think the auto-generated driver is a good idea.
>
> Part of the reason for a lot of the manual work in VxL is a historical
> disliking for too much "build system magic"; VxL's predecessor,
> TargetJr, had some pretty complex Makefiles that few very understood
> in detail. Part of the philosophy of VxL is to make it easy to
> integrate VxL into other applications, and not necessarily force folks
> into using the "VxL build system". In fact, ideally, there won't be a
> VxL build system. To this end, I think we should be careful not to
> over-do the build-time automation, but the tests sound reasonable to
> me. Of course, over time, CMake has proven cross-platform enough that
> it is (becoming) the de-facto VxL build system.
On 7/29/06, Peter Vanroose <peter_vanroose@...> wrote:
> > But now that I write that: Peter Vanroose maintains a pure Makefile
> > version of the build system. It may be that over-automation here may
> > affect his ability. Let's wait for a word from him.
>
> I agree with Amitha that we shouldn't pinpoint vxl too much on one build system (CMake); that's
> the only reason for still maintaining an independent build system. But I'm not putting too much
> time in it anymore, and I will probably soon remove it from the repository (if nobody objects).
So, to reiterate in case I am missunderstanding... I gather that we
shouldn't use too many fancy CMake constructs to *generate code* in
vxl making it easier for someone that doesn't use cmake to build and
integrate vxl into their app. However, in the case of tests which are
somewhat auxillary to the lib itself I can go ahead and make the
modifications.
That is, use the driver generated by cmake to replace the manually
edited one currently used and, also use the test_include.cxx generated
by cmake to replace the one currently in the source tree.
I'll assume that if there are no corrections, I can go ahead.
Thanks,
Miguel

Thread view

Hello maintainers,
If noone objects I'll add the following MACROS to
config/cmake/config/vxl_utils.cmake and test apply changes to vul/vil
to use them. I have attached the vxl_utils.cmake and a generated
test_include.cxx for your quick inspection.
--- First Macro
Motivated by the recent problem in vul's test_url.cxx with APPLE, I
tested a MACRO (attached below) that I have for generating the TEST
code for CMake in vul and vil (not in the io,algo subdirs, yet). In
summary, you don't need the test_driver.cxx that is currently
generated, and it replaces the ADD_EXECUTABLE/ADD_TEST commands with
the single line:
GENERATE_TEST_DRIVER(vul vul_test_sources vul vpl testlib vcl)
In case you need arguments passed, I've used the following convention
that works in vil:
SET(test_file_format_read_args ${CMAKE_CURRENT_SOURCE_DIR}/file_read_data)
SET(test_stream_args ${CMAKE_CURRENT_SOURCE_DIR}/file_read_data)
SET(test_convert_args ${CMAKE_CURRENT_SOURCE_DIR}/file_read_data)
SET(test_blocked_image_resource_args ${CMAKE_CURRENT_SOURCE_DIR}/file_read_data)
GENERATE_TEST_DRIVER(vil vil_test_sources vil vpl vul testlib vcl)
That is create a variable named after the file containing the test +
"_args" to hold the arguments.
I also had to manually change all tests to have a function with the
signature as in the following code, but in most cases this could be
done by redefining TESTMAIN:
//TESTMAIN(test_math_value_range);
int test_math_value_range(int, char*[])
{
testlib_test_start("test_math_value_range");
test_math_value_range();
return testlib_test_summary();
}
--- Second Macro
I have also created a GENERATE_TEST_INCLUDE, which replaces the two
lines adding the test_include.cxx file in the CMakeLists.txt, but also
generates the actual test_include.cxx. The command looks like:
GENERATE_TEST_INCLUDE(vil vil_sources "vil/")
#ADD_EXECUTABLE( vil_test_include test_include.cxx )
#TARGET_LINK_LIBRARIES( vil_test_include vil )
The way I generate it is that I take the vil_sources variable (from
the upper dir) and scan it for *.h files, then include it twice in the
generated test_include.cxx with the prefix "vil/" appended. Sample
output is appended for vil.
My only reservation with this is that I don't know if people have
manually added things to test_include.cxx that would need special
treatment. Also, it will add everything with a *.h extension including
impl things like:
#include <vil/file_formats/vil_png.h>
in vil (which is not a bad thing for a test, I guess).
----
Please, let me know any concerns or suggestions you may have.
--Miguel

On 7/19/06, Amitha Perera <perera@...> wrote:
> On Fri 14 Jul 2006, Miguel A. Figueroa-Villanueva wrote:
> > //TESTMAIN(test_math_value_range);
> > int test_math_value_range(int, char*[])
> > {
> > testlib_test_start("test_math_value_range");
> >
> > test_math_value_range();
> >
> > return testlib_test_summary();
> > }
>
> The testlib macros are designed to generate a "main" function with signature
> int test_name_main( int, char*[] )
>
> Pretty much every test should be conforming in this regard. If your
> generated code calls test_name_main() instead of test_name(), then you
> probably don't need to manually change any tests.
I thought about this already, but the other way around... make
TESTMAIN generate a test_name signature instead. The reason is that
this signature is generated by a CMake function
CREATE_TEST_SOURCELIST. So, I don't have access to changing it there.
I was planning to checkout a clean version of VXL and modify the
TESTMAIN definition and see if there are any conflicts, then post to
the list that I was planning to change it... but while we are at it,
is it ok? I don't foresee any major problems with this change, since
there is probably is no other "test_name(int, char*[])" function
defined...
--
There is also the issue with the generated test_include.cxx... If
people agree that this is the way to go, then every time I add the
GENERATE_TEST_INCLUDE(...) command, I should delete the manually coded
test_include.cxx file.
So, should I apply the use of GENERATE_TEST_DRIVER/INCLUDE all across
VXL. There is no big argument in favor of changing what is already
working, except that IMHO it is much easier and less error prone to
have it generated automatically. And of course, if everywhere we use
this then when newcomers look for an example they follow this
approach.
--Miguel

On Wed 19 Jul 2006, Miguel A. Figueroa-Villanueva wrote:
> I was planning to checkout a clean version of VXL and modify the
> TESTMAIN definition and see if there are any conflicts, then post to
> the list that I was planning to change it... but while we are at it,
> is it ok? I don't foresee any major problems with this change, since
> there is probably is no other "test_name(int, char*[])" function
> defined...
I think you will find some conflicts, but they should be few and
trivial to change. I think the auto-generated driver is a good idea.
Part of the reason for a lot of the manual work in VxL is a historical
disliking for too much "build system magic"; VxL's predecessor,
TargetJr, had some pretty complex Makefiles that few very understood
in detail. Part of the philosophy of VxL is to make it easy to
integrate VxL into other applications, and not necessarily force folks
into using the "VxL build system". In fact, ideally, there won't be a
VxL build system. To this end, I think we should be careful not to
over-do the build-time automation, but the tests sound reasonable to
me. Of course, over time, CMake has proven cross-platform enough that
it is (becoming) the de-facto VxL build system.
But now that I write that: Peter Vanroose maintains a pure Makefile
version of the build system. It may be that over-automation here may
affect his ability. Let's wait for a word from him.
Ditto for the include file list.
Amitha.

> But now that I write that: Peter Vanroose maintains a pure Makefile
> version of the build system. It may be that over-automation here may
> affect his ability. Let's wait for a word from him.
I agree with Amitha that we shouldn't pinpoint vxl too much on one build system (CMake); that's
the only reason for still maintaining an independent build system. But I'm not putting too much
time in it anymore, and I will probably soon remove it from the repository (if nobody objects).
-- Peter.

On 7/20/06, Amitha Perera <perera@...> wrote:
> I think you will find some conflicts, but they should be few and
> trivial to change. I think the auto-generated driver is a good idea.
>
> Part of the reason for a lot of the manual work in VxL is a historical
> disliking for too much "build system magic"; VxL's predecessor,
> TargetJr, had some pretty complex Makefiles that few very understood
> in detail. Part of the philosophy of VxL is to make it easy to
> integrate VxL into other applications, and not necessarily force folks
> into using the "VxL build system". In fact, ideally, there won't be a
> VxL build system. To this end, I think we should be careful not to
> over-do the build-time automation, but the tests sound reasonable to
> me. Of course, over time, CMake has proven cross-platform enough that
> it is (becoming) the de-facto VxL build system.
On 7/29/06, Peter Vanroose <peter_vanroose@...> wrote:
> > But now that I write that: Peter Vanroose maintains a pure Makefile
> > version of the build system. It may be that over-automation here may
> > affect his ability. Let's wait for a word from him.
>
> I agree with Amitha that we shouldn't pinpoint vxl too much on one build system (CMake); that's
> the only reason for still maintaining an independent build system. But I'm not putting too much
> time in it anymore, and I will probably soon remove it from the repository (if nobody objects).
So, to reiterate in case I am missunderstanding... I gather that we
shouldn't use too many fancy CMake constructs to *generate code* in
vxl making it easier for someone that doesn't use cmake to build and
integrate vxl into their app. However, in the case of tests which are
somewhat auxillary to the lib itself I can go ahead and make the
modifications.
That is, use the driver generated by cmake to replace the manually
edited one currently used and, also use the test_include.cxx generated
by cmake to replace the one currently in the source tree.
I'll assume that if there are no corrections, I can go ahead.
Thanks,
Miguel

On Sat 29 Jul 2006, Miguel A. Figueroa-Villanueva wrote:
> So, to reiterate in case I am missunderstanding... I gather that we
> shouldn't use too many fancy CMake constructs to *generate code* in
> vxl making it easier for someone that doesn't use cmake to build and
> integrate vxl into their app. However, in the case of tests which are
> somewhat auxillary to the lib itself I can go ahead and make the
> modifications.
I think your understanding is perfectly correct.
Amitha.