1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
#
# Copyright (c) 2016, The OpenThread Authors.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
# 1. Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# 3. Neither the name of the copyright holder nor the
# names of its contributors may be used to endorse or promote products
# derived from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.
#
include
#----------------------------------------
#
# This library on the face of it, appears to be identical
# for both the MTD and FTD variants, however ...
#
# The source code here includes numerous OpenThread internal headers.
# Due to the "domino-effect" other internal headers are included.
#
# For example:
# cli.cpp includes:
# src/core/common/instance.hpp
# Which Includes:
# src/core/therad/thread_netif.hpp
# Which Includes:
# src/core/meshcop/dataset_manager.hpp
# Which Includes:
# src/core/threadnetwork_data_leader.hpp
#
# That header (and others) is either an MTD or FTD class flavor.
#
# The FTD flavor has many private components (class variables).
# The MTD flavor has no private components.
#
# Bottom line: The Class(structs) are thus different in the downstream
# libs. At this level (in the CLI, and likewise in the NCP) they are
# functionally identical.
#
# ORIGINALLY (historical note about how things are/where built):
#
# The difference between MTD and FTD was a define.. -DOPENTHREAD_MTD
# There was no "FTD" define, it is/was assumed that FTD is the default.
#
# Historically this library -DOPENTHREAD_MTD was not defined/set.
# (it is set via a commandline define in 'lib-openthread')
#
# Thus, the existing(previous) way *THIS* library was compiled is
# exactly the FTD path. Meaning the "cli" library always sees
# the FTD varients of various headers/classes.
#
# The same is true of the "ncp" library.
#
# HOWEVER there are two varients of the CLI application, CLI-MTD
# and CLI-FTD (and likewise, two varients of the ncp application)
# These applications link against two different OpenThread libraries.
#
# Which flavor, you get depends upon which library: "mtd" or "ftd" is linked.
#
# Which on the surface appear to link fine against the MTD/FTD library.
#
# In this description/example we focus on the "nework_data_leader"
# header file. The FTD varient has many private variables, functions
# and other things of "FTD" (ie: full) implementation items.
#
# In contrast the MTD is generaly stubbed out with stub-functions
# inlined in the header that return "error not implemented" or similar.
#
# Thus it works... here ... With this file and this example.
#
# The unknown:
# What about the other files?
# What about the other c++ classes?
# Is this true always? Is this robust?
# Or is there a hidden "got-ya" that will snag the next person?
#
# This also fails static analisys, checks.
# Application - with MTD vrs FTD class.
# Library #1 (cli-lib) with FTD selected.
# Library #2 (openthread) with two different class flavors.
#
# The static analisys tools will say: "NOPE" different classes!
# Perhaps this will change if/when nothing is implemented in the 'mtd-header'
#
# Additionally, tools that perform "whole program optimization" will
# throw errors becuase the data structures differ greatly.
#
# Hence, CLI library (and NCP) must exist in two flavors.
#
# Unless and until these libraries do not "accidently" suck in
# a "flavored" header file somewhere.
lib_LIBRARIES =
if OPENTHREAD_ENABLE_FTD
lib_LIBRARIES +=
endif
if OPENTHREAD_ENABLE_MTD
lib_LIBRARIES +=
endif
CPPFLAGS_COMMON =
if OPENTHREAD_POSIX
CPPFLAGS_COMMON +=
else
CPPFLAGS_COMMON +=
endif
libopenthread_cli_mtd_a_CPPFLAGS =
libopenthread_cli_ftd_a_CPPFLAGS =
SOURCES_COMMON =
libopenthread_cli_ftd_a_SOURCES =
libopenthread_cli_mtd_a_SOURCES =
noinst_HEADERS =
if OPENTHREAD_BUILD_COVERAGE
CLEANFILES =
endif # OPENTHREAD_BUILD_COVERAGE
include