On 4/4/18 6:21 pm, Sebastian Huber wrote:
> On 04/04/18 10:10, Chris Johns wrote:
>> On 04/04/2018 18:03, Sebastian Huber wrote:
>>> On 04/04/18 09:55, Chris Johns wrote:
>>>>> I think we need only three Makefile.am and two configure.ac:
>>>>> configure.ac
>>>>> Makefile.am (builds also cpukit, uses AM_CONDITIONAL for 
>>>>> cpukit/score/cpu/*)
>>>>> testsuites/Makefile.am (uses AM_CONDITIONAL for each test)
>>>> 500+ tests in the one file? Really? I hope not.
>>> Is this better or worse than 794 Makefile.am in testsuites?
>> Worse, it becomes a conflict hot spot. One per functional group of tests may 
>> be
>> manageable.
> I have currently the naive point of view that the file will only contain lots 
> of
> stuff like this:
> rtems_tests_PROGRAMS += ticker
> ticker_SOURCES = samples/ticker/init.c samples/ticker/tasks.c

I wish. It is more like the following if the file system support code is built
as libraries, this steps around the recursive vs flat Makefile ideological
battle. This is an example of 5 tests:

include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
include $(top_srcdir)/../automake/compile.am
include $(top_srcdir)/../automake/leaf.am

fs_includes = \
        -I$(top_srcdir)/support \
        -I$(top_srcdir)/../support/include \

rtems_tests_PROGRAMS = \
        imfs_fspatheval \
        jffs2_fspatheval \
        mdosfs_fspatheval \
        mimfs_fspatheval \

imfs_fspatheval_SOURCES = test.c
imfs_fspatheval_LDLIBS = -L.. -lfs_support -limfs_support
imfs_fspatheval_CPPFLAGS = $(AM_CPPFLAGS) $(fs_includes)

jffs2_fspatheval_SOURCES = test.c
jffs2_fspatheval_LDLIBS = -L.. -lfs_support -ljffs2_support
jffs2_fspatheval_CPPFLAGS = $(AM_CPPFLAGS) $(fs_includes)

mdosfs_fspatheval_SOURCES = test.c
mdosfs_fspatheval_LDLIBS = -L.. -lfs_support -lmdosfs_support
mdosfs_fspatheval_CPPFLAGS = $(AM_CPPFLAGS) $(fs_includes)

mimfs_fspatheval_SOURCES = test.c
mimfs_fspatheval_LDLIBS = -L.. -lfs_support -lmimfs_support
mimfs_fspatheval_CPPFLAGS = $(AM_CPPFLAGS) $(fs_includes)

mrfs_fspatheval_SOURCES = test.c
mrfs_fspatheval_LDLIBS = -L.. -lfs_support -lmrfs_support
mrfs_fspatheval_CPPFLAGS = $(AM_CPPFLAGS) $(fs_includes)

dist_rtems_tests_DATA = \
        imfs_fspatheval.scn \
        jffs2_fspatheval.scn \
        mdosfs_fspatheval.scn \
        mimfs_fspatheval.scn \

It is looking like we need some more make variables to replace the defines for
the link items. The define is silly cause you cannot:

imfs_fspatheval$(EXEEXT): $(imfs_fspatheval_OBJECTS) 
        @rm -f imfs_fspatheval$(EXEEXT)
        $(make-exe) $(imfs_fspatheval_OBJECTS) $(imfs_fspatheval_LDLIBS)

The arguments to %(make-exe) are lost and you need to:

imfs_fspatheval$(EXEEXT): $(imfs_fspatheval_OBJECTS) 
        @rm -f imfs_fspatheval$(EXEEXT)
        $(call make-exe,$(imfs_fspatheval_OBJECTS),$(imfs_fspatheval_LDLIBS))

Joel has worked hard to converge to a single 'make-exe' which is key, this means
we might be able to turn into an automake link which is desirable. It means I
may be able to define another way and have automake handle the link. It is
typical of this build system that automake can build the object files but
linking is something different .... why? ... arrrrr .. ( no need to answer )

There are a small number of tests such as tar and libdl which are more
complicated because of multiple link passes and file generation. All these have
more steps.

You need to be sure the build rules are as simple as you say when you start. It
may pay to be more conservative and group at a lower level and then merge if you
can do this. Having said this a large single file is a conflict hot spot when
many people are adding tests.

devel mailing list

Reply via email to