📄 build.tests.html

📁 有关ecos2。0介绍了实时嵌入式的结构以及线程调度的实现和内存的管理等
💻 HTML
字号:
<!-- Copyright (C) 2003 Red Hat, Inc.                                --><!-- This material may be distributed only subject to the terms      --><!-- and conditions set forth in the Open Publication License, v1.0  --><!-- or later (the latest version is presently available at          --><!-- http://www.opencontent.org/openpub/).                           --><!-- Distribution of the work or derivative of the work in any       --><!-- standard (paper) book form is prohibited unless prior           --><!-- permission is obtained from the copyright holder.               --><HTML><HEAD><TITLE>Building Test Cases</TITLE><meta name="MSSmartTagsPreventParsing" content="TRUE"><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+"><LINKREL="HOME"TITLE="The eCos Component Writer's Guide"HREF="cdl-guide.html"><LINKREL="UP"TITLE="The Build Process"HREF="build.html"><LINKREL="PREVIOUS"TITLE="Building eCos"HREF="build.make.html"><LINKREL="NEXT"TITLE="CDL Language Specification"HREF="reference.html"></HEAD><BODYCLASS="SECT1"BGCOLOR="#FFFFFF"TEXT="#000000"LINK="#0000FF"VLINK="#840084"ALINK="#0000FF"><DIVCLASS="NAVHEADER"><TABLESUMMARY="Header navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">The <SPANCLASS="APPLICATION">eCos</SPAN> Component Writer's Guide</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="build.make.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom">Chapter 4. The Build Process</TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="reference.html"ACCESSKEY="N">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><DIVCLASS="SECT1"><H1CLASS="SECT1"><ANAME="BUILD.TESTS">Building Test Cases</H1><DIVCLASS="CAUTION"><P></P><TABLECLASS="CAUTION"BORDER="1"WIDTH="100%"><TR><TDALIGN="CENTER"><B>Caution</B></TD></TR><TR><TDALIGN="LEFT"><P>The support in the current implementation of the component frameworkfor building and running test cases is limited, and should be enhancedconsiderably in a future version. Compatibility with the existingmechanisms described below will be maintained if possible, but thiscannot be guaranteed.</P></TD></TR></TABLE></DIV><P>Whenever possible packages should be shipped with one or more testcases. This allows users to check that all packages function correctlyin their particular configuration and on their target, which may becustom hardware unavailable to the package developer. The componentframework needs to provide a way of building such test cases. Forexample, if a makefile system is used then there could be a<TTCLASS="LITERAL">make&nbsp;tests</TT> target to build the test cases, orpossibly a <TTCLASS="LITERAL">make&nbsp;check</TT> target to build and runthe test cases and process all the results. Unfortunately there arevarious complications.</P><P>Not every test case will be applicable to every configuration. Forexample if the user has disabled the C library's<TTCLASS="VARNAME">CYGPKG_LIBC_STDIO</TT> component then there is no pointin building or running any of the test cases for that component. Thisimplies that test cases need to be associated with configurationoptions somehow. It is possible for the test case to use one or more<TTCLASS="LITERAL">#ifdef</TT> statements to check whether or not it isapplicable in the current configuration, and compile to a null programwhen not applicable. This is inefficient because the test case willstill get built and possibly run, even though it will not provide anyuseful information.</P><P>Many packages involve direct interaction with hardware, for example aserial line or an ethernet interface. In such cases it is onlyworthwhile building and running the test if there is suitable softwarerunning at the other end of the serial line or listening on the sameethernet segment, and that software would typically have to run on thehost. Of course the serial line in question may be hooked up to adifferent piece of hardware which the application needs to talk to, sodisconnecting it and then hooking it up to the host for running sometests may be undesirable. The decision as to whether or not to buildthe test depends not just on the eCos configuration but also on thehardware setup and the availability of suitable host software.</P><P>There are different kinds of tests, and it is not always desirable torun all of them. For example a package may contain a number of stresstests intended to run for long periods of time, possibly days orlonger. Such tests should certainly be distinguished somehow fromordinary test cases so that users will not run them accidentally andwonder how long they should wait for a <TTCLASS="LITERAL">pass</TT> messagebefore giving up. Stress tests may also have dependencies on thehardware configuration and on host software, for example a networkstress test may require lots of ethernet packets.</P><P>In the current implementation of the component framework these issuesare not yet addressed. Instead there is only very limited support forbuilding test cases. Any package can define a calculated configurationoption of the form<TTCLASS="LITERAL">CYGPKG_&lt;package-name&gt;_TESTS</TT>, whose value is alist of test cases. The <SPANCLASS="PROPERTY">calculated</SPAN> property can involve anexpression so it is possible to adapt to a small number ofconfiguration options, but this quickly becomes unwieldy. A typicalexample would be:</P><TABLEBORDER="5"BGCOLOR="#E0E0F0"WIDTH="70%"><TR><TD><PRECLASS="PROGRAMLISTING">        cdl_option CYGPKG_UITRON_TESTS {            display "uITRON tests"            flavor  data            no_define            calculated { "tests/test1 tests/test2 tests/test3 \                tests/test4 tests/test5 tests/test6 tests/test7 \                tests/test8 tests/test9 tests/testcxx tests/testcx2 \                tests/testcx3 tests/testcx4 tests/testcx5 \                tests/testcx6 tests/testcx7 tests/testcx8 \                tests/testcx9 tests/testintr" }            description   "This option specifies the set of tests for the uITRON compatibility layer."        }</PRE></TD></TR></TABLE><P>This implies that there is a file <TTCLASS="FILENAME">tests/test1.c</TT>or <TTCLASS="FILENAME">tests/test1.cxx</TT> in the package's directory.The commands that will be used to build the test case will take theform:</P><TABLEBORDER="5"BGCOLOR="#E0E0F0"WIDTH="70%"><TR><TD><PRECLASS="PROGRAMLISTING">    $(CC) -c $(INCLUDE_PATH) $(CFLAGS) -o &lt;build path&gt;/test1.o \         &lt;source path&gt;/tests/test1.c    $(CC) $(LDFLAGS) -o &lt;install path&gt;/tests/test1 &lt;build_path&gt;/test1.o</PRE></TD></TR></TABLE><P>The variables <TTCLASS="LITERAL">$(CC)</TT> and so on are determined in thesame way as for custom build steps. The various paths and the currentdirectory will depend on the exact build system being used, and aresubject to change. As usual the sources in the component repositoryare treated as a read-only resources, intermediate files live in thebuild tree, and the desired executables should end up in the installtree. </P><P>Each test source file must be self-contained. It is not possible atpresent to build a little per-package library that can be used by thetest cases, or to link together several object files to produce asingle test executable. In some cases it may be possible to<TTCLASS="LITERAL">#include</TT> source code from a shared file in order toavoid unnecessary code replication. There is no support formanipulating compiler or linker flags for individual test cases: theflags that will be used for all files are <TTCLASS="LITERAL">$(CFLAGS)</TT>and <TTCLASS="LITERAL">$(LDFLAGS)</TT>, as per custom build steps. Notethat it is possible for a package to define options of the form<TTCLASS="VARNAME">CYGPKG_&lt;PACKAGE-NAME&gt;_LDFLAGS_ADD</TT> and<TTCLASS="VARNAME">CYGPKG_&lt;PACKAGE-NAME&gt;_LDFLAGS_REMOVE</TT>. Thesewill affect test cases, but in the absence of custom build steps theywill have no other effect on the build.</P></DIV><DIVCLASS="NAVFOOTER"><HRALIGN="LEFT"WIDTH="100%"><TABLESUMMARY="Footer navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top"><AHREF="build.make.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="cdl-guide.html"ACCESSKEY="H">Home</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top"><AHREF="reference.html"ACCESSKEY="N">Next</A></TD></TR><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top">Building eCos</TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="build.html"ACCESSKEY="U">Up</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top">CDL Language Specification</TD></TR></TABLE></DIV></BODY></HTML>
⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -