support aliyun sdk on TencentOS tiny
sample: examples\aliyun_iotkit_csdk_mqtt project: board\TencentOS_tiny_EVB_MX_Plus\KEIL\aliyun_iotkit_csdk_mqtt
This commit is contained in:
dcxajichu
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,14 @@
|
||||
Authors of kconfig-frontends.
|
||||
|
||||
The developers of the Linux kernel are the original authors of the kconfig
|
||||
parser and frontends. The list is too long to reproduce here, but you can
|
||||
get a pretty complete list from the Linux kernel repository logs:
|
||||
git shortlog scripts/kconfig
|
||||
|
||||
The packaging uses the GNU autotools build system, of which I
|
||||
will not try to list the many authors here.
|
||||
|
||||
The initial packaging was done by:
|
||||
"Yann E. MORIN" <yann.morin.1998@free.fr>
|
||||
|
||||
For a complete list, see the commit-logs of the kconfig repository.
|
||||
@@ -0,0 +1,357 @@
|
||||
|
||||
The kconfig parser and frontends are extracted from the Linux kernel
|
||||
source tree, which is covered by the GPLv2 only. As Linus Torvalds puts it:
|
||||
|
||||
> Also note that the only valid version of the GPL as far as the kernel
|
||||
> is concerned is _this_ particular version of the license (ie v2, not
|
||||
> v2.2 or v3.x or whatever), unless explicitly otherwise stated.
|
||||
|
||||
Although the above quote explictly mentions the Linux kernel, it is my
|
||||
understanding that the whole Linux kernel source tree is covered by this
|
||||
sentence, even non-kernel source code. As such, the license that applies
|
||||
to the kconfig parser and frontends, as published in this package, are
|
||||
also covered by this sentence, and available under the GPLv2, and not any
|
||||
other version of the GPL, unless otherwise stated.
|
||||
|
||||
----------------------------------------
|
||||
|
||||
GNU GENERAL PUBLIC LICENSE
|
||||
Version 2, June 1991
|
||||
|
||||
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
|
||||
51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
Preamble
|
||||
|
||||
The licenses for most software are designed to take away your
|
||||
freedom to share and change it. By contrast, the GNU General Public
|
||||
License is intended to guarantee your freedom to share and change free
|
||||
software--to make sure the software is free for all its users. This
|
||||
General Public License applies to most of the Free Software
|
||||
Foundation's software and to any other program whose authors commit to
|
||||
using it. (Some other Free Software Foundation software is covered by
|
||||
the GNU Library General Public License instead.) You can apply it to
|
||||
your programs, too.
|
||||
|
||||
When we speak of free software, we are referring to freedom, not
|
||||
price. Our General Public Licenses are designed to make sure that you
|
||||
have the freedom to distribute copies of free software (and charge for
|
||||
this service if you wish), that you receive source code or can get it
|
||||
if you want it, that you can change the software or use pieces of it
|
||||
in new free programs; and that you know you can do these things.
|
||||
|
||||
To protect your rights, we need to make restrictions that forbid
|
||||
anyone to deny you these rights or to ask you to surrender the rights.
|
||||
These restrictions translate to certain responsibilities for you if you
|
||||
distribute copies of the software, or if you modify it.
|
||||
|
||||
For example, if you distribute copies of such a program, whether
|
||||
gratis or for a fee, you must give the recipients all the rights that
|
||||
you have. You must make sure that they, too, receive or can get the
|
||||
source code. And you must show them these terms so they know their
|
||||
rights.
|
||||
|
||||
We protect your rights with two steps: (1) copyright the software, and
|
||||
(2) offer you this license which gives you legal permission to copy,
|
||||
distribute and/or modify the software.
|
||||
|
||||
Also, for each author's protection and ours, we want to make certain
|
||||
that everyone understands that there is no warranty for this free
|
||||
software. If the software is modified by someone else and passed on, we
|
||||
want its recipients to know that what they have is not the original, so
|
||||
that any problems introduced by others will not reflect on the original
|
||||
authors' reputations.
|
||||
|
||||
Finally, any free program is threatened constantly by software
|
||||
patents. We wish to avoid the danger that redistributors of a free
|
||||
program will individually obtain patent licenses, in effect making the
|
||||
program proprietary. To prevent this, we have made it clear that any
|
||||
patent must be licensed for everyone's free use or not licensed at all.
|
||||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow.
|
||||
|
||||
GNU GENERAL PUBLIC LICENSE
|
||||
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
||||
|
||||
0. This License applies to any program or other work which contains
|
||||
a notice placed by the copyright holder saying it may be distributed
|
||||
under the terms of this General Public License. The "Program", below,
|
||||
refers to any such program or work, and a "work based on the Program"
|
||||
means either the Program or any derivative work under copyright law:
|
||||
that is to say, a work containing the Program or a portion of it,
|
||||
either verbatim or with modifications and/or translated into another
|
||||
language. (Hereinafter, translation is included without limitation in
|
||||
the term "modification".) Each licensee is addressed as "you".
|
||||
|
||||
Activities other than copying, distribution and modification are not
|
||||
covered by this License; they are outside its scope. The act of
|
||||
running the Program is not restricted, and the output from the Program
|
||||
is covered only if its contents constitute a work based on the
|
||||
Program (independent of having been made by running the Program).
|
||||
Whether that is true depends on what the Program does.
|
||||
|
||||
1. You may copy and distribute verbatim copies of the Program's
|
||||
source code as you receive it, in any medium, provided that you
|
||||
conspicuously and appropriately publish on each copy an appropriate
|
||||
copyright notice and disclaimer of warranty; keep intact all the
|
||||
notices that refer to this License and to the absence of any warranty;
|
||||
and give any other recipients of the Program a copy of this License
|
||||
along with the Program.
|
||||
|
||||
You may charge a fee for the physical act of transferring a copy, and
|
||||
you may at your option offer warranty protection in exchange for a fee.
|
||||
|
||||
2. You may modify your copy or copies of the Program or any portion
|
||||
of it, thus forming a work based on the Program, and copy and
|
||||
distribute such modifications or work under the terms of Section 1
|
||||
above, provided that you also meet all of these conditions:
|
||||
|
||||
a) You must cause the modified files to carry prominent notices
|
||||
stating that you changed the files and the date of any change.
|
||||
|
||||
b) You must cause any work that you distribute or publish, that in
|
||||
whole or in part contains or is derived from the Program or any
|
||||
part thereof, to be licensed as a whole at no charge to all third
|
||||
parties under the terms of this License.
|
||||
|
||||
c) If the modified program normally reads commands interactively
|
||||
when run, you must cause it, when started running for such
|
||||
interactive use in the most ordinary way, to print or display an
|
||||
announcement including an appropriate copyright notice and a
|
||||
notice that there is no warranty (or else, saying that you provide
|
||||
a warranty) and that users may redistribute the program under
|
||||
these conditions, and telling the user how to view a copy of this
|
||||
License. (Exception: if the Program itself is interactive but
|
||||
does not normally print such an announcement, your work based on
|
||||
the Program is not required to print an announcement.)
|
||||
|
||||
These requirements apply to the modified work as a whole. If
|
||||
identifiable sections of that work are not derived from the Program,
|
||||
and can be reasonably considered independent and separate works in
|
||||
themselves, then this License, and its terms, do not apply to those
|
||||
sections when you distribute them as separate works. But when you
|
||||
distribute the same sections as part of a whole which is a work based
|
||||
on the Program, the distribution of the whole must be on the terms of
|
||||
this License, whose permissions for other licensees extend to the
|
||||
entire whole, and thus to each and every part regardless of who wrote it.
|
||||
|
||||
Thus, it is not the intent of this section to claim rights or contest
|
||||
your rights to work written entirely by you; rather, the intent is to
|
||||
exercise the right to control the distribution of derivative or
|
||||
collective works based on the Program.
|
||||
|
||||
In addition, mere aggregation of another work not based on the Program
|
||||
with the Program (or with a work based on the Program) on a volume of
|
||||
a storage or distribution medium does not bring the other work under
|
||||
the scope of this License.
|
||||
|
||||
3. You may copy and distribute the Program (or a work based on it,
|
||||
under Section 2) in object code or executable form under the terms of
|
||||
Sections 1 and 2 above provided that you also do one of the following:
|
||||
|
||||
a) Accompany it with the complete corresponding machine-readable
|
||||
source code, which must be distributed under the terms of Sections
|
||||
1 and 2 above on a medium customarily used for software interchange; or,
|
||||
|
||||
b) Accompany it with a written offer, valid for at least three
|
||||
years, to give any third party, for a charge no more than your
|
||||
cost of physically performing source distribution, a complete
|
||||
machine-readable copy of the corresponding source code, to be
|
||||
distributed under the terms of Sections 1 and 2 above on a medium
|
||||
customarily used for software interchange; or,
|
||||
|
||||
c) Accompany it with the information you received as to the offer
|
||||
to distribute corresponding source code. (This alternative is
|
||||
allowed only for noncommercial distribution and only if you
|
||||
received the program in object code or executable form with such
|
||||
an offer, in accord with Subsection b above.)
|
||||
|
||||
The source code for a work means the preferred form of the work for
|
||||
making modifications to it. For an executable work, complete source
|
||||
code means all the source code for all modules it contains, plus any
|
||||
associated interface definition files, plus the scripts used to
|
||||
control compilation and installation of the executable. However, as a
|
||||
special exception, the source code distributed need not include
|
||||
anything that is normally distributed (in either source or binary
|
||||
form) with the major components (compiler, kernel, and so on) of the
|
||||
operating system on which the executable runs, unless that component
|
||||
itself accompanies the executable.
|
||||
|
||||
If distribution of executable or object code is made by offering
|
||||
access to copy from a designated place, then offering equivalent
|
||||
access to copy the source code from the same place counts as
|
||||
distribution of the source code, even though third parties are not
|
||||
compelled to copy the source along with the object code.
|
||||
|
||||
4. You may not copy, modify, sublicense, or distribute the Program
|
||||
except as expressly provided under this License. Any attempt
|
||||
otherwise to copy, modify, sublicense or distribute the Program is
|
||||
void, and will automatically terminate your rights under this License.
|
||||
However, parties who have received copies, or rights, from you under
|
||||
this License will not have their licenses terminated so long as such
|
||||
parties remain in full compliance.
|
||||
|
||||
5. You are not required to accept this License, since you have not
|
||||
signed it. However, nothing else grants you permission to modify or
|
||||
distribute the Program or its derivative works. These actions are
|
||||
prohibited by law if you do not accept this License. Therefore, by
|
||||
modifying or distributing the Program (or any work based on the
|
||||
Program), you indicate your acceptance of this License to do so, and
|
||||
all its terms and conditions for copying, distributing or modifying
|
||||
the Program or works based on it.
|
||||
|
||||
6. Each time you redistribute the Program (or any work based on the
|
||||
Program), the recipient automatically receives a license from the
|
||||
original licensor to copy, distribute or modify the Program subject to
|
||||
these terms and conditions. You may not impose any further
|
||||
restrictions on the recipients' exercise of the rights granted herein.
|
||||
You are not responsible for enforcing compliance by third parties to
|
||||
this License.
|
||||
|
||||
7. If, as a consequence of a court judgment or allegation of patent
|
||||
infringement or for any other reason (not limited to patent issues),
|
||||
conditions are imposed on you (whether by court order, agreement or
|
||||
otherwise) that contradict the conditions of this License, they do not
|
||||
excuse you from the conditions of this License. If you cannot
|
||||
distribute so as to satisfy simultaneously your obligations under this
|
||||
License and any other pertinent obligations, then as a consequence you
|
||||
may not distribute the Program at all. For example, if a patent
|
||||
license would not permit royalty-free redistribution of the Program by
|
||||
all those who receive copies directly or indirectly through you, then
|
||||
the only way you could satisfy both it and this License would be to
|
||||
refrain entirely from distribution of the Program.
|
||||
|
||||
If any portion of this section is held invalid or unenforceable under
|
||||
any particular circumstance, the balance of the section is intended to
|
||||
apply and the section as a whole is intended to apply in other
|
||||
circumstances.
|
||||
|
||||
It is not the purpose of this section to induce you to infringe any
|
||||
patents or other property right claims or to contest validity of any
|
||||
such claims; this section has the sole purpose of protecting the
|
||||
integrity of the free software distribution system, which is
|
||||
implemented by public license practices. Many people have made
|
||||
generous contributions to the wide range of software distributed
|
||||
through that system in reliance on consistent application of that
|
||||
system; it is up to the author/donor to decide if he or she is willing
|
||||
to distribute software through any other system and a licensee cannot
|
||||
impose that choice.
|
||||
|
||||
This section is intended to make thoroughly clear what is believed to
|
||||
be a consequence of the rest of this License.
|
||||
|
||||
8. If the distribution and/or use of the Program is restricted in
|
||||
certain countries either by patents or by copyrighted interfaces, the
|
||||
original copyright holder who places the Program under this License
|
||||
may add an explicit geographical distribution limitation excluding
|
||||
those countries, so that distribution is permitted only in or among
|
||||
countries not thus excluded. In such case, this License incorporates
|
||||
the limitation as if written in the body of this License.
|
||||
|
||||
9. The Free Software Foundation may publish revised and/or new versions
|
||||
of the General Public License from time to time. Such new versions will
|
||||
be similar in spirit to the present version, but may differ in detail to
|
||||
address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the Program
|
||||
specifies a version number of this License which applies to it and "any
|
||||
later version", you have the option of following the terms and conditions
|
||||
either of that version or of any later version published by the Free
|
||||
Software Foundation. If the Program does not specify a version number of
|
||||
this License, you may choose any version ever published by the Free Software
|
||||
Foundation.
|
||||
|
||||
10. If you wish to incorporate parts of the Program into other free
|
||||
programs whose distribution conditions are different, write to the author
|
||||
to ask for permission. For software which is copyrighted by the Free
|
||||
Software Foundation, write to the Free Software Foundation; we sometimes
|
||||
make exceptions for this. Our decision will be guided by the two goals
|
||||
of preserving the free status of all derivatives of our free software and
|
||||
of promoting the sharing and reuse of software generally.
|
||||
|
||||
NO WARRANTY
|
||||
|
||||
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
|
||||
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
|
||||
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
|
||||
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
|
||||
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
|
||||
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
|
||||
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
|
||||
REPAIR OR CORRECTION.
|
||||
|
||||
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
|
||||
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
|
||||
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
|
||||
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
|
||||
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
|
||||
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
|
||||
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
|
||||
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGES.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
How to Apply These Terms to Your New Programs
|
||||
|
||||
If you develop a new program, and you want it to be of the greatest
|
||||
possible use to the public, the best way to achieve this is to make it
|
||||
free software which everyone can redistribute and change under these terms.
|
||||
|
||||
To do so, attach the following notices to the program. It is safest
|
||||
to attach them to the start of each source file to most effectively
|
||||
convey the exclusion of warranty; and each file should have at least
|
||||
the "copyright" line and a pointer to where the full notice is found.
|
||||
|
||||
<one line to give the program's name and a brief idea of what it does.>
|
||||
Copyright (C) <year> <name of author>
|
||||
|
||||
This program is free software; you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation; either version 2 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
||||
|
||||
|
||||
Also add information on how to contact you by electronic and paper mail.
|
||||
|
||||
If the program is interactive, make it output a short notice like this
|
||||
when it starts in an interactive mode:
|
||||
|
||||
Gnomovision version 69, Copyright (C) year name of author
|
||||
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
|
||||
This is free software, and you are welcome to redistribute it
|
||||
under certain conditions; type `show c' for details.
|
||||
|
||||
The hypothetical commands `show w' and `show c' should show the appropriate
|
||||
parts of the General Public License. Of course, the commands you use may
|
||||
be called something other than `show w' and `show c'; they could even be
|
||||
mouse-clicks or menu items--whatever suits your program.
|
||||
|
||||
You should also get your employer (if you work as a programmer) or your
|
||||
school, if any, to sign a "copyright disclaimer" for the program, if
|
||||
necessary. Here is a sample; alter the names:
|
||||
|
||||
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
|
||||
`Gnomovision' (which makes passes at compilers) written by James Hacker.
|
||||
|
||||
<signature of Ty Coon>, 1 April 1989
|
||||
Ty Coon, President of Vice
|
||||
|
||||
This General Public License does not permit incorporating your program into
|
||||
proprietary programs. If your program is a subroutine library, you may
|
||||
consider it more useful to permit linking proprietary applications with the
|
||||
library. If this is what you want to do, use the GNU Library General
|
||||
Public License instead of this License.
|
||||
@@ -0,0 +1 @@
|
||||
kconfig-mconf
|
||||
@@ -0,0 +1,626 @@
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The configuration database is a collection of configuration options
|
||||
organized in a tree structure:
|
||||
|
||||
+- Code maturity level options
|
||||
| +- Prompt for development and/or incomplete code/drivers
|
||||
+- General setup
|
||||
| +- Networking support
|
||||
| +- System V IPC
|
||||
| +- BSD Process Accounting
|
||||
| +- Sysctl support
|
||||
+- Loadable module support
|
||||
| +- Enable loadable module support
|
||||
| +- Set version information on all module symbols
|
||||
| +- Kernel module loader
|
||||
+- ...
|
||||
|
||||
Every entry has its own dependencies. These dependencies are used
|
||||
to determine the visibility of an entry. Any child entry is only
|
||||
visible if its parent entry is also visible.
|
||||
|
||||
Menu entries
|
||||
------------
|
||||
|
||||
Most entries define a config option; all other entries help to organize
|
||||
them. A single configuration option is defined like this:
|
||||
|
||||
config MODVERSIONS
|
||||
bool "Set version information on all module symbols"
|
||||
depends on MODULES
|
||||
help
|
||||
Usually, modules have to be recompiled whenever you switch to a new
|
||||
kernel. ...
|
||||
|
||||
Every line starts with a key word and can be followed by multiple
|
||||
arguments. "config" starts a new config entry. The following lines
|
||||
define attributes for this config option. Attributes can be the type of
|
||||
the config option, input prompt, dependencies, help text and default
|
||||
values. A config option can be defined multiple times with the same
|
||||
name, but every definition can have only a single input prompt and the
|
||||
type must not conflict.
|
||||
|
||||
Menu attributes
|
||||
---------------
|
||||
|
||||
A menu entry can have a number of attributes. Not all of them are
|
||||
applicable everywhere (see syntax).
|
||||
|
||||
- type definition: "bool"/"tristate"/"string"/"hex"/"int"
|
||||
Every config option must have a type. There are only two basic types:
|
||||
tristate and string; the other types are based on these two. The type
|
||||
definition optionally accepts an input prompt, so these two examples
|
||||
are equivalent:
|
||||
|
||||
bool "Networking support"
|
||||
and
|
||||
bool
|
||||
prompt "Networking support"
|
||||
|
||||
- input prompt: "prompt" <prompt> ["if" <expr>]
|
||||
Every menu entry can have at most one prompt, which is used to display
|
||||
to the user. Optionally dependencies only for this prompt can be added
|
||||
with "if".
|
||||
|
||||
- default value: "default" <expr> ["if" <expr>]
|
||||
A config option can have any number of default values. If multiple
|
||||
default values are visible, only the first defined one is active.
|
||||
Default values are not limited to the menu entry where they are
|
||||
defined. This means the default can be defined somewhere else or be
|
||||
overridden by an earlier definition.
|
||||
The default value is only assigned to the config symbol if no other
|
||||
value was set by the user (via the input prompt above). If an input
|
||||
prompt is visible the default value is presented to the user and can
|
||||
be overridden by him.
|
||||
Optionally, dependencies only for this default value can be added with
|
||||
"if".
|
||||
|
||||
- type definition + default value:
|
||||
"def_bool"/"def_tristate" <expr> ["if" <expr>]
|
||||
This is a shorthand notation for a type definition plus a value.
|
||||
Optionally dependencies for this default value can be added with "if".
|
||||
|
||||
- dependencies: "depends on" <expr>
|
||||
This defines a dependency for this menu entry. If multiple
|
||||
dependencies are defined, they are connected with '&&'. Dependencies
|
||||
are applied to all other options within this menu entry (which also
|
||||
accept an "if" expression), so these two examples are equivalent:
|
||||
|
||||
bool "foo" if BAR
|
||||
default y if BAR
|
||||
and
|
||||
depends on BAR
|
||||
bool "foo"
|
||||
default y
|
||||
|
||||
- reverse dependencies: "select" <symbol> ["if" <expr>]
|
||||
While normal dependencies reduce the upper limit of a symbol (see
|
||||
below), reverse dependencies can be used to force a lower limit of
|
||||
another symbol. The value of the current menu symbol is used as the
|
||||
minimal value <symbol> can be set to. If <symbol> is selected multiple
|
||||
times, the limit is set to the largest selection.
|
||||
Reverse dependencies can only be used with boolean or tristate
|
||||
symbols.
|
||||
Note:
|
||||
select should be used with care. select will force
|
||||
a symbol to a value without visiting the dependencies.
|
||||
By abusing select you are able to select a symbol FOO even
|
||||
if FOO depends on BAR that is not set.
|
||||
In general use select only for non-visible symbols
|
||||
(no prompts anywhere) and for symbols with no dependencies.
|
||||
That will limit the usefulness but on the other hand avoid
|
||||
the illegal configurations all over.
|
||||
|
||||
- weak reverse dependencies: "imply" <symbol> ["if" <expr>]
|
||||
This is similar to "select" as it enforces a lower limit on another
|
||||
symbol except that the "implied" symbol's value may still be set to n
|
||||
from a direct dependency or with a visible prompt.
|
||||
|
||||
Given the following example:
|
||||
|
||||
config FOO
|
||||
tristate
|
||||
imply BAZ
|
||||
|
||||
config BAZ
|
||||
tristate
|
||||
depends on BAR
|
||||
|
||||
The following values are possible:
|
||||
|
||||
FOO BAR BAZ's default choice for BAZ
|
||||
--- --- ------------- --------------
|
||||
n y n N/m/y
|
||||
m y m M/y/n
|
||||
y y y Y/n
|
||||
y n * N
|
||||
|
||||
This is useful e.g. with multiple drivers that want to indicate their
|
||||
ability to hook into a secondary subsystem while allowing the user to
|
||||
configure that subsystem out without also having to unset these drivers.
|
||||
|
||||
- limiting menu display: "visible if" <expr>
|
||||
This attribute is only applicable to menu blocks, if the condition is
|
||||
false, the menu block is not displayed to the user (the symbols
|
||||
contained there can still be selected by other symbols, though). It is
|
||||
similar to a conditional "prompt" attribute for individual menu
|
||||
entries. Default value of "visible" is true.
|
||||
|
||||
- numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
|
||||
This allows to limit the range of possible input values for int
|
||||
and hex symbols. The user can only input a value which is larger than
|
||||
or equal to the first symbol and smaller than or equal to the second
|
||||
symbol.
|
||||
|
||||
- help text: "help" or "---help---"
|
||||
This defines a help text. The end of the help text is determined by
|
||||
the indentation level, this means it ends at the first line which has
|
||||
a smaller indentation than the first line of the help text.
|
||||
"---help---" and "help" do not differ in behaviour, "---help---" is
|
||||
used to help visually separate configuration logic from help within
|
||||
the file as an aid to developers.
|
||||
|
||||
- misc options: "option" <symbol>[=<value>]
|
||||
Various less common options can be defined via this option syntax,
|
||||
which can modify the behaviour of the menu entry and its config
|
||||
symbol. These options are currently possible:
|
||||
|
||||
- "defconfig_list"
|
||||
This declares a list of default entries which can be used when
|
||||
looking for the default configuration (which is used when the main
|
||||
.config doesn't exists yet.)
|
||||
|
||||
- "modules"
|
||||
This declares the symbol to be used as the MODULES symbol, which
|
||||
enables the third modular state for all config symbols.
|
||||
At most one symbol may have the "modules" option set.
|
||||
|
||||
- "env"=<value>
|
||||
This imports the environment variable into Kconfig. It behaves like
|
||||
a default, except that the value comes from the environment, this
|
||||
also means that the behaviour when mixing it with normal defaults is
|
||||
undefined at this point. The symbol is currently not exported back
|
||||
to the build environment (if this is desired, it can be done via
|
||||
another symbol).
|
||||
|
||||
- "allnoconfig_y"
|
||||
This declares the symbol as one that should have the value y when
|
||||
using "allnoconfig". Used for symbols that hide other symbols.
|
||||
|
||||
Menu dependencies
|
||||
-----------------
|
||||
|
||||
Dependencies define the visibility of a menu entry and can also reduce
|
||||
the input range of tristate symbols. The tristate logic used in the
|
||||
expressions uses one more state than normal boolean logic to express the
|
||||
module state. Dependency expressions have the following syntax:
|
||||
|
||||
<expr> ::= <symbol> (1)
|
||||
<symbol> '=' <symbol> (2)
|
||||
<symbol> '!=' <symbol> (3)
|
||||
'(' <expr> ')' (4)
|
||||
'!' <expr> (5)
|
||||
<expr> '&&' <expr> (6)
|
||||
<expr> '||' <expr> (7)
|
||||
|
||||
Expressions are listed in decreasing order of precedence.
|
||||
|
||||
(1) Convert the symbol into an expression. Boolean and tristate symbols
|
||||
are simply converted into the respective expression values. All
|
||||
other symbol types result in 'n'.
|
||||
(2) If the values of both symbols are equal, it returns 'y',
|
||||
otherwise 'n'.
|
||||
(3) If the values of both symbols are equal, it returns 'n',
|
||||
otherwise 'y'.
|
||||
(4) Returns the value of the expression. Used to override precedence.
|
||||
(5) Returns the result of (2-/expr/).
|
||||
(6) Returns the result of min(/expr/, /expr/).
|
||||
(7) Returns the result of max(/expr/, /expr/).
|
||||
|
||||
An expression can have a value of 'n', 'm' or 'y' (or 0, 1, 2
|
||||
respectively for calculations). A menu entry becomes visible when its
|
||||
expression evaluates to 'm' or 'y'.
|
||||
|
||||
There are two types of symbols: constant and non-constant symbols.
|
||||
Non-constant symbols are the most common ones and are defined with the
|
||||
'config' statement. Non-constant symbols consist entirely of alphanumeric
|
||||
characters or underscores.
|
||||
Constant symbols are only part of expressions. Constant symbols are
|
||||
always surrounded by single or double quotes. Within the quote, any
|
||||
other character is allowed and the quotes can be escaped using '\'.
|
||||
|
||||
Menu structure
|
||||
--------------
|
||||
|
||||
The position of a menu entry in the tree is determined in two ways. First
|
||||
it can be specified explicitly:
|
||||
|
||||
menu "Network device support"
|
||||
depends on NET
|
||||
|
||||
config NETDEVICES
|
||||
...
|
||||
|
||||
endmenu
|
||||
|
||||
All entries within the "menu" ... "endmenu" block become a submenu of
|
||||
"Network device support". All subentries inherit the dependencies from
|
||||
the menu entry, e.g. this means the dependency "NET" is added to the
|
||||
dependency list of the config option NETDEVICES.
|
||||
|
||||
The other way to generate the menu structure is done by analyzing the
|
||||
dependencies. If a menu entry somehow depends on the previous entry, it
|
||||
can be made a submenu of it. First, the previous (parent) symbol must
|
||||
be part of the dependency list and then one of these two conditions
|
||||
must be true:
|
||||
- the child entry must become invisible, if the parent is set to 'n'
|
||||
- the child entry must only be visible, if the parent is visible
|
||||
|
||||
config MODULES
|
||||
bool "Enable loadable module support"
|
||||
|
||||
config MODVERSIONS
|
||||
bool "Set version information on all module symbols"
|
||||
depends on MODULES
|
||||
|
||||
comment "module support disabled"
|
||||
depends on !MODULES
|
||||
|
||||
MODVERSIONS directly depends on MODULES, this means it's only visible if
|
||||
MODULES is different from 'n'. The comment on the other hand is only
|
||||
visible when MODULES is set to 'n'.
|
||||
|
||||
|
||||
Kconfig syntax
|
||||
--------------
|
||||
|
||||
The configuration file describes a series of menu entries, where every
|
||||
line starts with a keyword (except help texts). The following keywords
|
||||
end a menu entry:
|
||||
- config
|
||||
- menuconfig
|
||||
- choice/endchoice
|
||||
- comment
|
||||
- menu/endmenu
|
||||
- if/endif
|
||||
- source
|
||||
The first five also start the definition of a menu entry.
|
||||
|
||||
config:
|
||||
|
||||
"config" <symbol>
|
||||
<config options>
|
||||
|
||||
This defines a config symbol <symbol> and accepts any of above
|
||||
attributes as options.
|
||||
|
||||
menuconfig:
|
||||
"menuconfig" <symbol>
|
||||
<config options>
|
||||
|
||||
This is similar to the simple config entry above, but it also gives a
|
||||
hint to front ends, that all suboptions should be displayed as a
|
||||
separate list of options. To make sure all the suboptions will really
|
||||
show up under the menuconfig entry and not outside of it, every item
|
||||
from the <config options> list must depend on the menuconfig symbol.
|
||||
In practice, this is achieved by using one of the next two constructs:
|
||||
|
||||
(1):
|
||||
menuconfig M
|
||||
if M
|
||||
config C1
|
||||
config C2
|
||||
endif
|
||||
|
||||
(2):
|
||||
menuconfig M
|
||||
config C1
|
||||
depends on M
|
||||
config C2
|
||||
depends on M
|
||||
|
||||
In the following examples (3) and (4), C1 and C2 still have the M
|
||||
dependency, but will not appear under menuconfig M anymore, because
|
||||
of C0, which doesn't depend on M:
|
||||
|
||||
(3):
|
||||
menuconfig M
|
||||
config C0
|
||||
if M
|
||||
config C1
|
||||
config C2
|
||||
endif
|
||||
|
||||
(4):
|
||||
menuconfig M
|
||||
config C0
|
||||
config C1
|
||||
depends on M
|
||||
config C2
|
||||
depends on M
|
||||
|
||||
choices:
|
||||
|
||||
"choice" [symbol]
|
||||
<choice options>
|
||||
<choice block>
|
||||
"endchoice"
|
||||
|
||||
This defines a choice group and accepts any of the above attributes as
|
||||
options. A choice can only be of type bool or tristate. If no type is
|
||||
specified for a choice, it's type will be determined by the type of
|
||||
the first choice element in the group or remain unknown if none of the
|
||||
choice elements have a type specified, as well.
|
||||
|
||||
While a boolean choice only allows a single config entry to be
|
||||
selected, a tristate choice also allows any number of config entries
|
||||
to be set to 'm'. This can be used if multiple drivers for a single
|
||||
hardware exists and only a single driver can be compiled/loaded into
|
||||
the kernel, but all drivers can be compiled as modules.
|
||||
|
||||
A choice accepts another option "optional", which allows to set the
|
||||
choice to 'n' and no entry needs to be selected.
|
||||
If no [symbol] is associated with a choice, then you can not have multiple
|
||||
definitions of that choice. If a [symbol] is associated to the choice,
|
||||
then you may define the same choice (ie. with the same entries) in another
|
||||
place.
|
||||
|
||||
comment:
|
||||
|
||||
"comment" <prompt>
|
||||
<comment options>
|
||||
|
||||
This defines a comment which is displayed to the user during the
|
||||
configuration process and is also echoed to the output files. The only
|
||||
possible options are dependencies.
|
||||
|
||||
menu:
|
||||
|
||||
"menu" <prompt>
|
||||
<menu options>
|
||||
<menu block>
|
||||
"endmenu"
|
||||
|
||||
This defines a menu block, see "Menu structure" above for more
|
||||
information. The only possible options are dependencies and "visible"
|
||||
attributes.
|
||||
|
||||
if:
|
||||
|
||||
"if" <expr>
|
||||
<if block>
|
||||
"endif"
|
||||
|
||||
This defines an if block. The dependency expression <expr> is appended
|
||||
to all enclosed menu entries.
|
||||
|
||||
source:
|
||||
|
||||
"source" <prompt>
|
||||
|
||||
This reads the specified configuration file. This file is always parsed.
|
||||
|
||||
mainmenu:
|
||||
|
||||
"mainmenu" <prompt>
|
||||
|
||||
This sets the config program's title bar if the config program chooses
|
||||
to use it. It should be placed at the top of the configuration, before any
|
||||
other statement.
|
||||
|
||||
|
||||
Kconfig hints
|
||||
-------------
|
||||
This is a collection of Kconfig tips, most of which aren't obvious at
|
||||
first glance and most of which have become idioms in several Kconfig
|
||||
files.
|
||||
|
||||
Adding common features and make the usage configurable
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
It is a common idiom to implement a feature/functionality that are
|
||||
relevant for some architectures but not all.
|
||||
The recommended way to do so is to use a config variable named HAVE_*
|
||||
that is defined in a common Kconfig file and selected by the relevant
|
||||
architectures.
|
||||
An example is the generic IOMAP functionality.
|
||||
|
||||
We would in lib/Kconfig see:
|
||||
|
||||
# Generic IOMAP is used to ...
|
||||
config HAVE_GENERIC_IOMAP
|
||||
|
||||
config GENERIC_IOMAP
|
||||
depends on HAVE_GENERIC_IOMAP && FOO
|
||||
|
||||
And in lib/Makefile we would see:
|
||||
obj-$(CONFIG_GENERIC_IOMAP) += iomap.o
|
||||
|
||||
For each architecture using the generic IOMAP functionality we would see:
|
||||
|
||||
config X86
|
||||
select ...
|
||||
select HAVE_GENERIC_IOMAP
|
||||
select ...
|
||||
|
||||
Note: we use the existing config option and avoid creating a new
|
||||
config variable to select HAVE_GENERIC_IOMAP.
|
||||
|
||||
Note: the use of the internal config variable HAVE_GENERIC_IOMAP, it is
|
||||
introduced to overcome the limitation of select which will force a
|
||||
config option to 'y' no matter the dependencies.
|
||||
The dependencies are moved to the symbol GENERIC_IOMAP and we avoid the
|
||||
situation where select forces a symbol equals to 'y'.
|
||||
|
||||
Build as module only
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
To restrict a component build to module-only, qualify its config symbol
|
||||
with "depends on m". E.g.:
|
||||
|
||||
config FOO
|
||||
depends on BAR && m
|
||||
|
||||
limits FOO to module (=m) or disabled (=n).
|
||||
|
||||
Kconfig recursive dependency limitations
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you've hit the Kconfig error: "recursive dependency detected" you've run
|
||||
into a recursive dependency issue with Kconfig, a recursive dependency can be
|
||||
summarized as a circular dependency. The kconfig tools need to ensure that
|
||||
Kconfig files comply with specified configuration requirements. In order to do
|
||||
that kconfig must determine the values that are possible for all Kconfig
|
||||
symbols, this is currently not possible if there is a circular relation
|
||||
between two or more Kconfig symbols. For more details refer to the "Simple
|
||||
Kconfig recursive issue" subsection below. Kconfig does not do recursive
|
||||
dependency resolution; this has a few implications for Kconfig file writers.
|
||||
We'll first explain why this issues exists and then provide an example
|
||||
technical limitation which this brings upon Kconfig developers. Eager
|
||||
developers wishing to try to address this limitation should read the next
|
||||
subsections.
|
||||
|
||||
Simple Kconfig recursive issue
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Read: Documentation/kbuild/Kconfig.recursion-issue-01
|
||||
|
||||
Test with:
|
||||
|
||||
make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-01 allnoconfig
|
||||
|
||||
Cumulative Kconfig recursive issue
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Read: Documentation/kbuild/Kconfig.recursion-issue-02
|
||||
|
||||
Test with:
|
||||
|
||||
make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 allnoconfig
|
||||
|
||||
Practical solutions to kconfig recursive issue
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Developers who run into the recursive Kconfig issue have three options
|
||||
at their disposal. We document them below and also provide a list of
|
||||
historical issues resolved through these different solutions.
|
||||
|
||||
a) Remove any superfluous "select FOO" or "depends on FOO"
|
||||
b) Match dependency semantics:
|
||||
b1) Swap all "select FOO" to "depends on FOO" or,
|
||||
b2) Swap all "depends on FOO" to "select FOO"
|
||||
c) Consider the use of "imply" instead of "select"
|
||||
|
||||
The resolution to a) can be tested with the sample Kconfig file
|
||||
Documentation/kbuild/Kconfig.recursion-issue-01 through the removal
|
||||
of the "select CORE" from CORE_BELL_A_ADVANCED as that is implicit already
|
||||
since CORE_BELL_A depends on CORE. At times it may not be possible to remove
|
||||
some dependency criteria, for such cases you can work with solution b).
|
||||
|
||||
The two different resolutions for b) can be tested in the sample Kconfig file
|
||||
Documentation/kbuild/Kconfig.recursion-issue-02.
|
||||
|
||||
Below is a list of examples of prior fixes for these types of recursive issues;
|
||||
all errors appear to involve one or more select's and one or more "depends on".
|
||||
|
||||
commit fix
|
||||
====== ===
|
||||
06b718c01208 select A -> depends on A
|
||||
c22eacfe82f9 depends on A -> depends on B
|
||||
6a91e854442c select A -> depends on A
|
||||
118c565a8f2e select A -> select B
|
||||
f004e5594705 select A -> depends on A
|
||||
c7861f37b4c6 depends on A -> (null)
|
||||
80c69915e5fb select A -> (null) (1)
|
||||
c2218e26c0d0 select A -> depends on A (1)
|
||||
d6ae99d04e1c select A -> depends on A
|
||||
95ca19cf8cbf select A -> depends on A
|
||||
8f057d7bca54 depends on A -> (null)
|
||||
8f057d7bca54 depends on A -> select A
|
||||
a0701f04846e select A -> depends on A
|
||||
0c8b92f7f259 depends on A -> (null)
|
||||
e4e9e0540928 select A -> depends on A (2)
|
||||
7453ea886e87 depends on A > (null) (1)
|
||||
7b1fff7e4fdf select A -> depends on A
|
||||
86c747d2a4f0 select A -> depends on A
|
||||
d9f9ab51e55e select A -> depends on A
|
||||
0c51a4d8abd6 depends on A -> select A (3)
|
||||
e98062ed6dc4 select A -> depends on A (3)
|
||||
91e5d284a7f1 select A -> (null)
|
||||
|
||||
(1) Partial (or no) quote of error.
|
||||
(2) That seems to be the gist of that fix.
|
||||
(3) Same error.
|
||||
|
||||
Future kconfig work
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Work on kconfig is welcomed on both areas of clarifying semantics and on
|
||||
evaluating the use of a full SAT solver for it. A full SAT solver can be
|
||||
desirable to enable more complex dependency mappings and / or queries,
|
||||
for instance on possible use case for a SAT solver could be that of handling
|
||||
the current known recursive dependency issues. It is not known if this would
|
||||
address such issues but such evaluation is desirable. If support for a full SAT
|
||||
solver proves too complex or that it cannot address recursive dependency issues
|
||||
Kconfig should have at least clear and well defined semantics which also
|
||||
addresses and documents limitations or requirements such as the ones dealing
|
||||
with recursive dependencies.
|
||||
|
||||
Further work on both of these areas is welcomed on Kconfig. We elaborate
|
||||
on both of these in the next two subsections.
|
||||
|
||||
Semantics of Kconfig
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The use of Kconfig is broad, Linux is now only one of Kconfig's users:
|
||||
one study has completed a broad analysis of Kconfig use in 12 projects [0].
|
||||
Despite its widespread use, and although this document does a reasonable job
|
||||
in documenting basic Kconfig syntax a more precise definition of Kconfig
|
||||
semantics is welcomed. One project deduced Kconfig semantics through
|
||||
the use of the xconfig configurator [1]. Work should be done to confirm if
|
||||
the deduced semantics matches our intended Kconfig design goals.
|
||||
|
||||
Having well defined semantics can be useful for tools for practical
|
||||
evaluation of depenencies, for instance one such use known case was work to
|
||||
express in boolean abstraction of the inferred semantics of Kconfig to
|
||||
translate Kconfig logic into boolean formulas and run a SAT solver on this to
|
||||
find dead code / features (always inactive), 114 dead features were found in
|
||||
Linux using this methodology [1] (Section 8: Threats to validity).
|
||||
|
||||
Confirming this could prove useful as Kconfig stands as one of the the leading
|
||||
industrial variability modeling languages [1] [2]. Its study would help
|
||||
evaluate practical uses of such languages, their use was only theoretical
|
||||
and real world requirements were not well understood. As it stands though
|
||||
only reverse engineering techniques have been used to deduce semantics from
|
||||
variability modeling languages such as Kconfig [3].
|
||||
|
||||
[0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf
|
||||
[1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
|
||||
[2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf
|
||||
[3] http://gsd.uwaterloo.ca/sites/default/files/icse2011.pdf
|
||||
|
||||
Full SAT solver for Kconfig
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Although SAT solvers [0] haven't yet been used by Kconfig directly, as noted in
|
||||
the previous subsection, work has been done however to express in boolean
|
||||
abstraction the inferred semantics of Kconfig to translate Kconfig logic into
|
||||
boolean formulas and run a SAT solver on it [1]. Another known related project
|
||||
is CADOS [2] (former VAMOS [3]) and the tools, mainly undertaker [4], which has
|
||||
been introduced first with [5]. The basic concept of undertaker is to exract
|
||||
variability models from Kconfig, and put them together with a propositional
|
||||
formula extracted from CPP #ifdefs and build-rules into a SAT solver in order
|
||||
to find dead code, dead files, and dead symbols. If using a SAT solver is
|
||||
desirable on Kconfig one approach would be to evaluate repurposing such efforts
|
||||
somehow on Kconfig. There is enough interest from mentors of existing projects
|
||||
to not only help advise how to integrate this work upstream but also help
|
||||
maintain it long term. Interested developers should visit:
|
||||
|
||||
http://kernelnewbies.org/KernelProjects/kconfig-sat
|
||||
|
||||
[0] http://www.cs.cornell.edu/~sabhar/chapters/SATSolvers-KR-Handbook.pdf
|
||||
[1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
|
||||
[2] https://cados.cs.fau.de
|
||||
[3] https://vamos.cs.fau.de
|
||||
[4] https://undertaker.cs.fau.de
|
||||
[5] https://www4.cs.fau.de/Publications/2011/tartler_11_eurosys.pdf
|
||||
@@ -0,0 +1,212 @@
|
||||
#! /bin/sh
|
||||
|
||||
SCRIPTDIR=`dirname $0`
|
||||
SCRIPTNAME=`basename $0`
|
||||
|
||||
# frontends/mconf/$SCRIPTNAME - temporary wrapper script for .libs/$SCRIPTNAME
|
||||
# Generated by libtool (GNU libtool) 2.4.6
|
||||
#
|
||||
# The frontends/mconf/$SCRIPTNAME program cannot be directly executed until all the libtool
|
||||
# libraries that it depends on are installed.
|
||||
#
|
||||
# This wrapper script should never be moved out of the build directory.
|
||||
# If it is, it will not operate correctly.
|
||||
|
||||
# Sed substitution that helps us do robust quoting. It backslashifies
|
||||
# metacharacters that are still active within double-quoted strings.
|
||||
sed_quote_subst='s|\([`"$\\]\)|\\\1|g'
|
||||
|
||||
# Be Bourne compatible
|
||||
if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
|
||||
emulate sh
|
||||
NULLCMD=:
|
||||
# Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which
|
||||
# is contrary to our usage. Disable this feature.
|
||||
alias -g '${1+"$@"}'='"$@"'
|
||||
setopt NO_GLOB_SUBST
|
||||
else
|
||||
case `(set -o) 2>/dev/null` in *posix*) set -o posix;; esac
|
||||
fi
|
||||
BIN_SH=xpg4; export BIN_SH # for Tru64
|
||||
DUALCASE=1; export DUALCASE # for MKS sh
|
||||
|
||||
# The HP-UX ksh and POSIX shell print the target directory to stdout
|
||||
# if CDPATH is set.
|
||||
(unset CDPATH) >/dev/null 2>&1 && unset CDPATH
|
||||
|
||||
relink_command=""
|
||||
|
||||
# This environment variable determines our operation mode.
|
||||
if test "$libtool_install_magic" = "%%%MAGIC variable%%%"; then
|
||||
# install mode needs the following variables:
|
||||
generated_by_libtool_version='2.4.6'
|
||||
notinst_deplibs=' ./libs/parser/libkconfig-parser.la'
|
||||
else
|
||||
# When we are sourced in execute mode, $file and $ECHO are already set.
|
||||
if test "$libtool_execute_magic" != "%%%MAGIC variable%%%"; then
|
||||
file="$0"
|
||||
|
||||
# A function that is used when there is no print builtin or printf.
|
||||
func_fallback_echo ()
|
||||
{
|
||||
eval 'cat <<_LTECHO_EOF
|
||||
$1
|
||||
_LTECHO_EOF'
|
||||
}
|
||||
ECHO="printf %s\\n"
|
||||
fi
|
||||
|
||||
# Very basic option parsing. These options are (a) specific to
|
||||
# the libtool wrapper, (b) are identical between the wrapper
|
||||
# /script/ and the wrapper /executable/ that is used only on
|
||||
# windows platforms, and (c) all begin with the string --lt-
|
||||
# (application programs are unlikely to have options that match
|
||||
# this pattern).
|
||||
#
|
||||
# There are only two supported options: --lt-debug and
|
||||
# --lt-dump-script. There is, deliberately, no --lt-help.
|
||||
#
|
||||
# The first argument to this parsing function should be the
|
||||
# script's ./libtool value, followed by no.
|
||||
lt_option_debug=
|
||||
func_parse_lt_options ()
|
||||
{
|
||||
lt_script_arg0=$0
|
||||
shift
|
||||
for lt_opt
|
||||
do
|
||||
case "$lt_opt" in
|
||||
--lt-debug) lt_option_debug=1 ;;
|
||||
--lt-dump-script)
|
||||
lt_dump_D=`$ECHO "X$lt_script_arg0" | /usr/bin/sed -e 's/^X//' -e 's%/[^/]*$%%'`
|
||||
test "X$lt_dump_D" = "X$lt_script_arg0" && lt_dump_D=.
|
||||
lt_dump_F=`$ECHO "X$lt_script_arg0" | /usr/bin/sed -e 's/^X//' -e 's%^.*/%%'`
|
||||
cat "$lt_dump_D/$lt_dump_F"
|
||||
exit 0
|
||||
;;
|
||||
--lt-*)
|
||||
$ECHO "Unrecognized --lt- option: '$lt_opt'" 1>&2
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
done
|
||||
|
||||
# Print the debug banner immediately:
|
||||
if test -n "$lt_option_debug"; then
|
||||
echo "$SCRIPTNAME:frontends/mconf/$SCRIPTNAME:$LINENO: libtool wrapper (GNU libtool) 2.4.6" 1>&2
|
||||
fi
|
||||
}
|
||||
|
||||
# Used when --lt-debug. Prints its arguments to stdout
|
||||
# (redirection is the responsibility of the caller)
|
||||
func_lt_dump_args ()
|
||||
{
|
||||
lt_dump_args_N=1;
|
||||
for lt_arg
|
||||
do
|
||||
$ECHO "$SCRIPTNAME:frontends/mconf/$SCRIPTNAME:$LINENO: newargv[$lt_dump_args_N]: $lt_arg"
|
||||
lt_dump_args_N=`expr $lt_dump_args_N + 1`
|
||||
done
|
||||
}
|
||||
|
||||
# Core function for launching the target application
|
||||
func_exec_program_core ()
|
||||
{
|
||||
|
||||
if test -n "$lt_option_debug"; then
|
||||
$ECHO "$SCRIPTNAME:frontends/mconf/$SCRIPTNAME:$LINENO: newargv[0]: $progdir/$program" 1>&2
|
||||
func_lt_dump_args ${1+"$@"} 1>&2
|
||||
fi
|
||||
exec "$progdir/$program" ${1+"$@"}
|
||||
|
||||
$ECHO "$0: cannot exec $program $*" 1>&2
|
||||
exit 1
|
||||
}
|
||||
|
||||
# A function to encapsulate launching the target application
|
||||
# Strips options in the --lt-* namespace from $@ and
|
||||
# launches target application with the remaining arguments.
|
||||
func_exec_program ()
|
||||
{
|
||||
case " $* " in
|
||||
*\ --lt-*)
|
||||
for lt_wr_arg
|
||||
do
|
||||
case $lt_wr_arg in
|
||||
--lt-*) ;;
|
||||
*) set x "$@" "$lt_wr_arg"; shift;;
|
||||
esac
|
||||
shift
|
||||
done ;;
|
||||
esac
|
||||
func_exec_program_core ${1+"$@"}
|
||||
}
|
||||
|
||||
# Parse options
|
||||
func_parse_lt_options "$0" ${1+"$@"}
|
||||
|
||||
# Find the directory that this script lives in.
|
||||
thisdir=`$ECHO "$file" | /usr/bin/sed 's%/[^/]*$%%'`
|
||||
test "x$thisdir" = "x$file" && thisdir=.
|
||||
|
||||
# Follow symbolic links until we get to the real thisdir.
|
||||
file=`ls -ld "$file" | /usr/bin/sed -n 's/.*-> //p'`
|
||||
while test -n "$file"; do
|
||||
destdir=`$ECHO "$file" | /usr/bin/sed 's%/[^/]*$%%'`
|
||||
|
||||
# If there was a directory component, then change thisdir.
|
||||
if test "x$destdir" != "x$file"; then
|
||||
case "$destdir" in
|
||||
[\\/]* | [A-Za-z]:[\\/]*) thisdir="$destdir" ;;
|
||||
*) thisdir="$thisdir/$destdir" ;;
|
||||
esac
|
||||
fi
|
||||
|
||||
file=`$ECHO "$file" | /usr/bin/sed 's%^.*/%%'`
|
||||
file=`ls -ld "$thisdir/$file" | /usr/bin/sed -n 's/.*-> //p'`
|
||||
done
|
||||
|
||||
# Usually 'no', except on cygwin/mingw when embedded into
|
||||
# the cwrapper.
|
||||
WRAPPER_SCRIPT_BELONGS_IN_OBJDIR=no
|
||||
if test "$WRAPPER_SCRIPT_BELONGS_IN_OBJDIR" = "yes"; then
|
||||
# special case for '.'
|
||||
if test "$thisdir" = "."; then
|
||||
thisdir=`pwd`
|
||||
fi
|
||||
# remove .libs from thisdir
|
||||
case "$thisdir" in
|
||||
*[\\/].libs ) thisdir=`$ECHO "$thisdir" | /usr/bin/sed 's%[\\/][^\\/]*$%%'` ;;
|
||||
.libs ) thisdir=. ;;
|
||||
esac
|
||||
fi
|
||||
|
||||
# Try to get the absolute directory name.
|
||||
absdir=`cd "$thisdir" && pwd`
|
||||
test -n "$absdir" && thisdir="$absdir"
|
||||
|
||||
program="$SCRIPTNAME"
|
||||
progdir="$SCRIPTDIR/.libs"
|
||||
|
||||
if test -f "$progdir/$program"; then
|
||||
# Add our own library path to DYLD_LIBRARY_PATH
|
||||
DYLD_LIBRARY_PATH="$SCRIPTDIR/.libs:$DYLD_LIBRARY_PATH"
|
||||
|
||||
# Some systems cannot cope with colon-terminated DYLD_LIBRARY_PATH
|
||||
# The second colon is a workaround for a bug in BeOS R4 sed
|
||||
DYLD_LIBRARY_PATH=`$ECHO "$DYLD_LIBRARY_PATH" | /usr/bin/sed 's/::*$//'`
|
||||
|
||||
export DYLD_LIBRARY_PATH
|
||||
|
||||
if test "$libtool_execute_magic" != "%%%MAGIC variable%%%"; then
|
||||
# Run the actual program with our arguments.
|
||||
func_exec_program ${1+"$@"}
|
||||
fi
|
||||
else
|
||||
# The program doesn't exist.
|
||||
$ECHO "$0: error: '$progdir/$program' does not exist" 1>&2
|
||||
$ECHO "This script is just a wrapper for $program." 1>&2
|
||||
$ECHO "See the libtool documentation for more information." 1>&2
|
||||
exit 1
|
||||
fi
|
||||
fi
|
||||
Reference in New Issue
Block a user