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 \
-I$(top_srcdir)/../psxtests/include
rtems_tests_PROGRAMS = \
imfs_fspatheval \
jffs2_fspatheval \
mdosfs_fspatheval \
mimfs_fspatheval \
mrfs_fspatheval
imfs_fspatheval_SOURCES = test.c
imfs_fspatheval_LDLIBS = -L.. -lfs_support -limfs_support
imfs_fspatheval_CPPFLAGS = $(AM_CPPFLAGS) $(fs_includes)
-I$(top_srcdir)/imfs_support
jffs2_fspatheval_SOURCES = test.c
jffs2_fspatheval_LDLIBS = -L.. -lfs_support -ljffs2_support
jffs2_fspatheval_CPPFLAGS = $(AM_CPPFLAGS) $(fs_includes)
-I$(top_srcdir)/jffs2_support
mdosfs_fspatheval_SOURCES = test.c
mdosfs_fspatheval_LDLIBS = -L.. -lfs_support -lmdosfs_support
mdosfs_fspatheval_CPPFLAGS = $(AM_CPPFLAGS) $(fs_includes)
-I$(top_srcdir)/mdosfs_support
mimfs_fspatheval_SOURCES = test.c
mimfs_fspatheval_LDLIBS = -L.. -lfs_support -lmimfs_support
mimfs_fspatheval_CPPFLAGS = $(AM_CPPFLAGS) $(fs_includes)
-I$(top_srcdir)/mimfs_support
mrfs_fspatheval_SOURCES = test.c
mrfs_fspatheval_LDLIBS = -L.. -lfs_support -lmrfs_support
mrfs_fspatheval_CPPFLAGS = $(AM_CPPFLAGS) $(fs_includes)
-I$(top_srcdir)/mrfs_support
dist_rtems_tests_DATA = \
imfs_fspatheval.scn \
jffs2_fspatheval.scn \
mdosfs_fspatheval.scn \
mimfs_fspatheval.scn \
mrfs_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)
$(imfs_fspatheval_DEPENDENCIES)
@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)
$(imfs_fspatheval_DEPENDENCIES)
@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.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
