Initial start of converting the Word outline to Rest

Thanks to Scott Zemerick <scott.zemerick@tmctechnologies.com> for
the analysis and ideas that led to this.
This commit is contained in:
Joel Sherrill 2018-11-21 10:39:04 -06:00
parent f29d91d0f3
commit 1ae5e889fb
31 changed files with 650 additions and 0 deletions

7
eng/README Normal file
View File

@ -0,0 +1,7 @@
This is a work in process. The initial parts of
RTEMS-Engineering-Standards-v3.docx have been converted to Rest. The
remaining sections need to be converted. And as marked, there are
sections where content from the Wiki needs to be converted to Rest
and included directly here.
--joel

83
eng/appendix-a.rst Normal file
View File

@ -0,0 +1,83 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Appendix: Core Qualification Artifacts/Documents
************************************************
An effort at NASA has been performed to suggest a core set of artifacts
(as defined by BOTH NASA NPR 7150.2B and DO-178B) that can be utilized
by a mission as a baselined starting point for “pre-qualification”
for (open-source) software that is intended to be utilized for flight
purposes. This effort analyzed the overlap between NPR 7150.2B
and DO-178B and highlighted a core set of artifacts to serve as a
starting point for any open-source project. These artifacts were also
cross-referenced with similar activities for other NASA flight software
qualification efforts, such as the open-source Core Flight System (cFS).
Along with the specific artifact, the intent of the artifact was also
captured; in some cases open-source projects, such as RTEMS, are already
meeting the intent of the artifacts with information simply needing
organized and formalized. The table below lists the general category,
artifact name, and its intent. Please note that this table does NOT
represent all the required artifacts for qualification per the standards;
instead, this table represents a subset of the most basic/core artifacts
that form a strong foundation for a software engineering qualification
effort.
TBD convert to a table; see original PDF for guidance on desired look
TBD The PDF is in https://ftp.rtems.org/pub/rtems/people/joel/sw_eng_hb/
.. COMMENT: ====================================== BEGIN
Table 1. Core Qualification Artifacts
Category Artifact Intent
Requirements Software Requirements Specification (SRS)
Requirements Management The project shall document the software requirements.
The project shall collect and manage changes to the software requirements.
The project shall identify, initiate corrective actions, and track until closure inconsistencies among requirements, project plans, and software products.
Requirements Test and Traceability Matrix The project shall perform, document, and maintain bidirectional traceability between the software requirement and the higher-level requirement.
Validation The project shall perform requirements validation to ensure that the software will perform as intended in the customer environment.
Design and Implementation Software Development or Management Plan A plan for how you will develop the software that you are intent upon developing and delivering.
The Software Development Plan includes the objectives, standards and life cycle(s) to be used in the software development process. This plan should include: Standards: Identification of the Software Requirements Standards, Software Design Standards, and Software Code Standards for the project.
Software Configuration Management Plan To identify and control major software changes, ensure that change is being properly implemented, and report changes to any other personnel or clients who may have an interest.
Implementation The project shall implement the software design into software code.
Executable Code to applicable tested software.
Coding Standards Report The project shall ensure that software coding methods, standards, and/or criteria are adhered to and verified.
Version Description Document (VDD) The project shall provide a Software Version Description document for each software release.
Testing and Software Assurance Activities Software Test Plan Document describing the testing scope and activities.
Software Assurance/Testing Procedures
To define the techniques, procedures, and methodologies that will be used.
Software Change Report / Problem Report The project shall regularly hold reviews of software activities, status, and results with the project stakeholders and track issues to resolution.
Software Schedule Milestones have schedule and schedule is updated accordingly.
Software Test Report / Verification Results The project shall record, address, and track to closure the results of software verification activities.
Problem report - Describes the process non-compliance with plans, output deficiency, or software anomalous behavior, and the corrective action taken.
The project shall ensure that the software code is unit tested per the plans for software testing.
Usability Software Users Manual The Software User Manual defines user instructions for the software.
.. COMMENT: ====================================== END
In an effort to remain lightweight and sustainable for open-source
projects, Table 1 above was condensed into a single artifact outline
that encompasses the artifacts intents. The idea is that this living
qualification document will reside under RTEMS source control and be
updated with additional detail accordingly. The artifact outline is
as follows:

14
eng/change-management.rst Normal file
View File

@ -0,0 +1,14 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Change Management
*****************
Major decisions about RTEMS are made by the core developers in concert
with the user community, guided by the Mission Statement. We provide
access to our development sources via a Git Repository (see these
Instructions for details).
TBD - ??? what in the Wiki could go here

10
eng/change-reports.rst Normal file
View File

@ -0,0 +1,10 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Software Change Report Generation
*********************************
TBD - What goes here?

10
eng/coding-80cols.rst Normal file
View File

@ -0,0 +1,10 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Eighty Character Line Limit
***************************
TBD - Convert the following to Rest and insert into this file
TBD - https://devel.rtems.org/wiki/Developer/Coding/80_characters_per_line

View File

@ -0,0 +1,10 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Coding Conventions
******************
TBD - Convert the following to Rest and insert into this file
TBD - https://devel.rtems.org/wiki/Developer/Coding/Conventions

View File

@ -0,0 +1,10 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Deprectating Interfaces
***********************
TBD - Convert the following to Rest and insert into this file
TBD - https://devel.rtems.org/wiki/Developer/Coding/Deprecating

View File

@ -0,0 +1,10 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
BSP Doxygen Recommentations
===========================
TBD - Convert the following to Rest and insert into this file
TBD - https://devel.rtems.org/wiki/Developer/Coding/Doxygen_for_BSPs

10
eng/coding-doxygen.rst Normal file
View File

@ -0,0 +1,10 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
General Doxygen Recommentations
===============================
TBD - Convert the following to Rest and insert into this file
TBD - https://devel.rtems.org/wiki/Developer/Coding/Doxygen

10
eng/coding-file-hdr.rst Normal file
View File

@ -0,0 +1,10 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Boilerplate File Header
***********************
TBD - Convert the following to Rest and insert into this file
TBD - https://devel.rtems.org/wiki/Developer/Coding/Boilerplate_File_Header

10
eng/coding-gen-patch.rst Normal file
View File

@ -0,0 +1,10 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Generating a Tools Patch
************************
TBD - Convert the following to Rest and insert into this file
TBD - https://devel.rtems.org/wiki/Developer/Coding/GenerateAPatch

10
eng/coding-naming.rst Normal file
View File

@ -0,0 +1,10 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Naming Rules
************
TBD - Convert the following to Rest and insert into this file
TBD - https://devel.rtems.org/wiki/Developer/Coding/NamingRules

21
eng/coding.rst Normal file
View File

@ -0,0 +1,21 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Coding Standards
****************
TBD - Write introduction, re-order, identify missing content
.. COMMENT: Subsections
.. toctree::
coding-conventions
coding-80cols
coding-deprecating
coding-doxygen-bsp
coding-doxygen
coding-file-hdr
coding-gen-patch
coding-naming

14
eng/conf.py Normal file
View File

@ -0,0 +1,14 @@
import sys, os
sys.path.append(os.path.abspath('../common/'))
from conf import *
project = "RTEMS Software Engineering Handbook"
latex_documents = [
('index',
'software-engineering-handbook.tex',
u'RTEMS Software Engineering Handbook',
u'RTEMS Documentation Project',
'manual'),
]

61
eng/index.rst Normal file
View File

@ -0,0 +1,61 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 1988-2008.
.. COMMENT: On-Line Applications Research Corporation (OAR).
.. COMMENT: COPYRIGHT (c) 2016-2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
================================================
RTEMS Software Engineering Handbook (|version|).
================================================
| **COPYRIGHT (c) 1988 - 2015.**
| **On-Line Applications Research Corporation (OAR).**
| **COPYRIGHT (c) 2016-2018.**
| **RTEMS Foundation, The RTEMS Documentation Project**
| **License:**
| Creative Commons Attribution-ShareAlike 4.0 International Public License
| https://creativecommons.org/licenses/by-sa/4.0/legalcode
The authors have used their best efforts in preparing this material. These
efforts include the development, research, and testing of the theories and
programs to determine their effectiveness. No warranty of any kind, expressed
or implied, with regard to the software or the material contained in this
document is provided. No liability arising out of the application or use of
any product described in this document is assumed. The authors reserve the
right to revise this material and to make changes from time to time in the
content hereof without obligation to notify anyone of such revision or changes.
The RTEMS Project is hosted at http://www.rtems.org/. Any inquiries concerning
RTEMS, its related support components, or its documentation should be directed
to the Community Project hosted at http://www.rtems.org/.
.. topic:: RTEMS Online Resources
================ =============================
Home https://www.rtems.org/
Developers https://devel.rtems.org/
Documentation https://docs.rtems.org/
Bug Reporting https://devel.rtems.org/query
Mailing Lists https://lists.rtems.org/
Git Repositories https://git.rtems.org/
================ =============================
.. toctree::
:maxdepth: 4
:numbered:
preface
prequalification
stakeholders
management
test-plan
release-mgmt
users-manuals
license-requirements
appendix-a
function_and_variable
concept
* :ref:`genindex`

21
eng/issue-tracking.rst Normal file
View File

@ -0,0 +1,21 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Issue Tracking
**************
TBD Review process, workflows, etc
TBD - This covers Issue Tracking and Trac usage
Need instructions which weave useful URLs including ones like these
https://devel.rtems.org/query
https://devel.rtems.org/wiki/NewTicket
Filing a Change Request or Problem Report
=========================================
The RTEMS Project uses Trac to manage all change requests and problem reports
and refers to either as a ticket. Ticket may be filed or viewed at
https://devel.rtems.org/wiki/Release

View File

@ -0,0 +1,23 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Licensing Requirements
**********************
All artifacts shall adhere to RTEMS Project licensing
requirements. Currently, the preferred licenses are CC-BY-SA-4.0 license
for documentation and “Two Paragraph BSD” for source code.
Historically, RTEMS has been licensed under the GPL v2 with linking
exception (https://www.rtems.org/license). It is preferred that new
submissions be under one of the two preferred licenses. If you have
previously submitted code to RTEMS under a historical license, please
grant the project permission to relicense. See
https://devel.rtems.org/ticket/3053 for details.
TBD - Convert the following to Rest and insert into this file
TBD - https://devel.rtems.org/wiki/Developer/Coding/Conventions#Licenses

20
eng/management.rst Normal file
View File

@ -0,0 +1,20 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Software Development Management
*******************************
TBD - Convert https://devel.rtems.org/wiki/TBR/Website/WhyContribute to Rest
TBD - and insert here
.. COMMENT: Subsections
.. toctree::
vc-users
vc-authors
coding
change-management
issue-tracking

29
eng/preface.rst Normal file
View File

@ -0,0 +1,29 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Preface
*******
The Real Time Executive for Multiprocessor Systems (RTEMS) operating
systems is a layered system with each of the public APIs implemented in
terms of a common foundation layer called the SuperCore. RTEMS provides
full capabilities for management of tasks, interrupts time, and multiple
processors in addition to those features typical of generic operating
systems. RTEMS has been implemented in both the Ada and C programming
languages.
.. topic: RTEMS Mission Statement
RTEMS development aims to provide a free deterministic real-time operating
system targeted towards deeply embedded systems which is competitive
with closed source products. The RTEMS project encourages the support
and use of standard APIs in order to promote application portability
and ease porting other packages to the RTEMS environment. Source:
https://devel.rtems.org/wiki/Mission_Statement
The RTEMS development effort uses an open development environment in
which all users collaborate to improve RTEMS. The RTEMS cross development
toolset is based upon the free GNU tools and the open source C Library
newlib. RTEMS supports many host platforms and target architectures.

80
eng/prequalification.rst Normal file
View File

@ -0,0 +1,80 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 1988-2008.
.. COMMENT: On-Line Applications Research Corporation (OAR).
.. COMMENT: COPYRIGHT (c) 2016-2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Introduction to Pre-Qualification
*********************************
RTEMS has a long history of being used to support critical
applications. In some of these application domains, there are standards
(e.g., DO-178C, NPR 7150.2) which define the expectations for the
processes used to develop software and the associated artifacts. These
standards typically do not specify software functionality but address
topics like requirements definition, traceability, having a documented
change process, coding style, testing requirements, and a users
manual. During system test, these standards call for a review usually
by an independent entity that the standard has been adhered too. These
reviews cover a broad variety of topics and activities, but the process
is generally referred to as qualification, verification, or auditing
against the specific standard in use. The RTEMS Project will use the
term “qualification” independent of the standard.
The goal of the RTEMS Qualification Project is to make RTEMS easier
to review regardless of the standard chosen. Quite specifically,
the RTEMS Qualification effort will NOT produce a directly qualified
product or artifacts in the format dictated by a specific organization
or standard. The goal is to make RTEMS itself, documentation, testing
infrastructure, etc. more closely align with the information requirements
of these high integrity qualification standards. In addition to improving
the items that a mature, high quality open source project will have,
there are additional artifacts needed for a qualification effort that
no known open source project possesses. Specifically, requirements and
the associated traceability to source code, tests, and documentation
are needed.
The RTEMS Qualification Project is technically
“pre-qualification”. True qualification must be performed on the
projects target hardware in a system context. The FAA has provided
guidance for Reusable Software Components (FAA-AC20-148) and this
effort should follow that guidance. The open RTEMS Project, with the
assistance of domain experts, will possess and maintain the master
technical information needed in a qualification effort. Consultants
will provide the services required to tailor the master information,
perform testing on specific system hardware, and to guide end users in
using the master technical data in the context of a particular standard.
The RTEMS Qualification Project will broadly address two areas. The
first area is suggesting areas of improvement for automated project
infrastructure and the master technical data that has traditionally been
provided by the RTEMS Project. For example, the RTEMS Qualification could
suggest specific improvements to code coverage reports. The teams focused
on qualification should be able to provide resources for improving the
automated project infrastructure and master technical data for RTEMS. The
term “resources” is often used by open source projects to refer to
volunteer code contributions or funding. Although code contributions in
this area are important and always welcome, funding is also important. At
a minimum, ongoing funding is needed for maintenance and upgrades of
the RTEMS Project server infrastructure, addition of services to those
servers, and core contributors to review submissions
The second area is the creation and maintenance of master technical
data that has traditionally not been owned or maintained by the RTEMS
Project. The most obvious example of this is a requirements set with
proper infrastructure for tracing requirements through code to test
and documentation. It is expected that these will be maintained by the
RTEMS Qualification Project. They will be evaluated for adoption by
the main RTEMS Project but the additional maintenance burden imposed
will be a strong factor in this consideration. It behooves the RTEMS
Qualification Project to limit dependence on manual checks and ensure
that automation and ongoing support for that automation is contributed
to the RTEMS Project.
It is expected that the RTEMS Qualification Project will create and
maintain maps from the RTEMS master technical data to the various
qualification standards. It will maintain “scorecards” which
identify how the RTEMS Project is currently doing when reviewed per each
standard. These will be maintained in the open as community resources
which will guide the community in improving its infrastructure.

17
eng/release-mgmt.rst Normal file
View File

@ -0,0 +1,17 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Software Release Management
***************************
TBD write content
.. COMMENT: Subsections
.. toctree::
change-reports
vdd-generation

23
eng/stakeholders.rst Normal file
View File

@ -0,0 +1,23 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
RTEMS Stakeholders
******************
RTEMS is a community based open source project. All users are treated
as stakeholders. It is hoped that as stakeholders, users will contribute
to the project, sponsor core developers, and help fund the infrastructure
required to host and manage the project.
Qualification - Stakeholder Involvement
=======================================
Qualification of RTEMS is a specialized activity and only specific users
of RTEMS will complete a formal qualification activity. The RTEMS Project
cannot self-fund this entire activity and requires stakeholder to invest
in an ongoing basis to ensure the any investment they make is maintained
and viable in an ongoing basis. The RTEMS core developers view steady
support of the qualification effort as necessary to continue to lower
the overall costs of qualification RTEMS.

42
eng/test-plan.rst Normal file
View File

@ -0,0 +1,42 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Software Test Plan Assurance and Procedures
********************************************
Testing and Coverage
====================
Testing to verify that requirements are implemented is a critical part of
the high integrity processes. Similarly, measuring and reporting source
and decision path coverage of source code is critical.
Needed improvements to the RTEMS testing infrastructure should be done
as part of the open project. Similarly, improvements in RTEMS coverage
reporting should be done as part of the open project. Both of these
capabilities are part of the RTEMS Tester toolset.
Assuming that a requirements focused test suite is added to the open
RTEMS, tools will be needed to assist in verifying that requirements are
“fully tested.” A fully tested requirement is one which is implemented
and tested with associated logical tracing. Tools automating this analysis
and generating reporting and alerts will be a critical part of ensuring
the master technical data does not bit rot.
Must use tools from:
TBD - Change URL to git.rtems.org and list support tools
RTEMS Tools Project: https://github.com/RTEMS/rtems-tools
Scope, Procedures, Methodologies, Tools
TBD - Write content
.. COMMENT: Subsections
.. toctree::
test-suites
tester

12
eng/test-suites.rst Normal file
View File

@ -0,0 +1,12 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Test Suites
***********
TBD - Convert the following to Rest and insert into this file
TBD from https://devel.rtems.org/wiki/Developer/Testing/TestSuites
TBD also update list of tests based on rtems/testsuites

12
eng/tester.rst Normal file
View File

@ -0,0 +1,12 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
RTEMS Tester
************
TBD - Convert the following to Rest and insert into this file
TBD https://devel.rtems.org/wiki/Testing/Tester
TBD - Above file is horribly out of date. Find new docs and refer to them

34
eng/users-manuals.rst Normal file
View File

@ -0,0 +1,34 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
User's Manuals
**************
TBD - write and link to useful documentation, potential URLs:
Reference the RTEMS C Users Manual
* https://docs.rtems.org/doc-current/share/rtems/pdf/c_user.pdf
Reference any other existing user documentation
* https://docs.rtems.org/doxygen/cpukit/html/index.html
* https://devel.rtems.org/
* http://www.rtems.com/
* https://www.rtems.org/onlinedocs.html
* https://devel.rtems.org/wiki/Developer/Contributing
* https://docs.rtems.org/releases/rtemsdocs-4.10.1/share/rtems/html/
Documentation Style Guidelines
==============================
TBD - write me

11
eng/vc-authors.rst Normal file
View File

@ -0,0 +1,11 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Software Development (Git Writers)
**********************************
TBD - Convert https://devel.rtems.org/wiki/Developer/Git/Committers
TBD - and insert here.

11
eng/vc-users.rst Normal file
View File

@ -0,0 +1,11 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Software Development (Git Users)
********************************
TBD - Convert https://devel.rtems.org/wiki/Developer/Git/Users to Rest
TBD - and insert here.

13
eng/vdd-generation.rst Normal file
View File

@ -0,0 +1,13 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. COMMENT: COPYRIGHT (c) 2018.
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
Version Description Document (VDD) Generation
*********************************************
TBD - discuss how generated. Preferably Dannie's project
This URL may be of use but it probably Trac auto-generated and can
only be referenced: https://devel.rtems.org/wiki/TracChangeLog

11
eng/wscript Normal file
View File

@ -0,0 +1,11 @@
from sys import path
from os.path import abspath
path.append(abspath('../common/'))
from waf import cmd_configure as configure
from waf import cmd_build as build
from waf import cmd_options as options
from waf import spell
from waf import cmd_spell
from waf import linkcheck
from waf import cmd_linkcheck

View File

@ -17,6 +17,7 @@ build_all = ['user',
'bsp-howto',
'posix-users',
'posix-compliance',
'eng',
'filesystem',
'networking',
'shell',