原创 2012年03月29日 17:12:49




本文介绍了Android.mk build file的语法


An Android.mk file is written to describe your sources to the
build system. More specifically:

- The file is really a tiny GNU Makefile fragment that will be
  parsed one or more times by the build system. As such, you
  should try to minimize the variables you declare there and
  do not assume that anything is not defined during parsing.
这个文件有可能被build system build多次,所以,需要尽可能少的声明变量。

- The file syntax is designed to allow you to group your
  sources into 'modules'. A module is one of the following:

    - a static library
    - a shared library
  Only shared libraries will be installed/copied to your
  application package. Static libraries can be used to generate
  shared libraries though.
只有shared libraries可以被installed/copied到你的application package中。
Static library可以被用来生成shared libraries。

  You can define one or more modules in each Android.mk file,
  and you can use the same source file in several modules.
可以再一个Android.mk文件中定义一个或多个modules,也可以在几个modules中使用同一个source file。

- The build system handles many details for you. For example, you
  don't need to list header files or explicit dependencies between
  generated files in your Android.mk. The NDK build system will
  compute these automatically for you.
build system处理了很多细节。例如,不需要列出头文件和详尽的依赖关系。
  This also means that, when updating to newer releases of the NDK,
  you should be able to benefit from new toolchain/platform support
  without having to touch your Android.mk files.

Note that the syntax is *very* close to the one used in Android.mk files
distributed with the full open-source Android platform sources. While
the build system implementation that uses them is different, this is
an intentional design decision made to allow reuse of 'external' libraries'
source code easier for application developers.
Simple example:

Before describing the syntax in details, let's consider the simple
"hello JNI" example, i.e. the files under:
先来看看最简单的hello JNI

Here, we can see:

  - The 'src' directory containing the Java sources for the
    sample Android project.
  - The 'jni' directory containing the native source for
    the sample, i.e. 'jni/hello-jni.c'
    jni目录包含native code
    This source file implements a simple shared library that
    implements a native method that returns a string to the
    VM application.
    它实现了一个简单的shared library,实现了一个native method,它向VM application返回一个string
  - The 'jni/Android.mk' file that describes the shared library
    to the NDK build system. Its content is:
   ---------- cut here ------------------
   LOCAL_PATH := $(call my-dir)

   include $(CLEAR_VARS)

   LOCAL_MODULE    := hello-jni
   LOCAL_SRC_FILES := hello-jni.c

   ---------- cut here ------------------

Now, let's explain these lines:

  LOCAL_PATH := $(call my-dir)

An Android.mk file must begin with the definition of the LOCAL_PATH variable.
It is used to locate source files in the development tree. In this example,
the macro function 'my-dir', provided by the build system, is used to return
the path of the current directory (i.e. the directory containing the
Android.mk file itself).
一个Android.mk文件必须以对LOCAL_PATH variable的定义开始,它被用来定位source files。
在这个例子中,build system提供的宏my-dir,用来返回当前目录的路径

  include $(CLEAR_VARS)

The CLEAR_VARS variable is provided by the build system and points to a
special GNU Makefile that will clear many LOCAL_XXX variables for you
with the exception of LOCAL_PATH. This is needed because all build
control files are parsed in a single GNU Make execution context where
all variables are global.
清除LOCAL_XXX variables。这个是必须的,因为所有的build control files在一个单独的GNU Make execution context中解析,所有的变量都是全局的

  LOCAL_MODULE := hello-jni

The LOCAL_MODULE variable must be defined to identify each module you
describe in your Android.mk. The name must be *unique* and not contain
any spaces. Note that the build system will automatically add proper
prefix and suffix to the corresponding generated file. In other words,
a shared library module named 'foo' will generate 'libfoo.so'.
LOCAL_MODULE variable用来标识每一个module。名称必须是唯一的,并且不能包含空格。build system将自动的添加合适的前缀和后缀,比如,一个叫做foo的shared library module将被生成libfoo.so

If you name your module 'libfoo', the build system will not
add another 'lib' prefix and will generate libfoo.so as well.
This is to support Android.mk files that originate from the
Android platform sources, would you need to use these.
如果你的module名是libfoo,build system将不会添加前缀lib。

  LOCAL_SRC_FILES := hello-jni.c

The LOCAL_SRC_FILES variables must contain a list of C and/or C++ source
files that will be built and assembled into a module. Note that you should
not list header and included files here, because the build system will
compute dependencies automatically for you; just list the source files
that will be passed directly to a compiler, and you should be good.
LOCAL_SRC_FILES包含C和C++的source files列表,它们将被built和assembled到module中

Note that the default extension for C++ source files is '.cpp'. It is
however possible to specify a different one by defining the variable
LOCAL_CPP_EXTENSION. Don't forget the initial dot (i.e. '.cxx' will
work, but not 'cxx').


The BUILD_SHARED_LIBRARY is a variable provided by the build system that
points to a GNU Makefile script that is in charge of collecting all the
information you defined in LOCAL_XXX variables since the latest
'include $(CLEAR_VARS)' and determine what to build, and how to do it
exactly. There is also BUILD_STATIC_LIBRARY to generate a static library.
BUILD_SHARED_LIBRARY 指向一段有build system提供的GNU Makefile script,它用来搜集所有的LOCAL_XXX信息,来决定build什么和怎么去做
BUILD_STATIC_LIBRARY 用来生成static library
There are more complex examples in the samples directories, with commentedAndroid.mk files that you can look at.Reference:----------This is the list of variables you should either rely on or define inan Android.mk. You can define other variables for your own usage, butthe NDK build system reserves the following variable names:
NDK build system保留的名字:

- names that begin with LOCAL_  (e.g. LOCAL_MODULE)
- names that begin with PRIVATE_, NDK_ or APP_  (used internally)
- lower-case names (used internally, e.g. 'my-dir')

If you need to define your own convenience variables in an Android.mk
file, we recommend using the MY_ prefix, for a trivial example:
   ---------- cut here ------------------
    MY_SOURCES := foo.c
    ifneq ($(MY_CONFIG_BAR),)
      MY_SOURCES += bar.c

   ---------- cut here ------------------
NDK-provided variables:
- - - - - - - - - - - -
These GNU Make variables are defined by the build system before
your Android.mk file is parsed. Note that under certain circumstances
the NDK might parse your Android.mk several times, each with different
definition for some of these variables.

    Points to a build script that undefines nearly all LOCAL_XXX variables
    listed in the "Module-description" section below. You must include
    the script before starting a new module, e.g.:

      include $(CLEAR_VARS)
    Points to a build script that collects all the information about the
    module you provided in LOCAL_XXX variables and determines how to build
    a target shared library from the sources you listed. Note that you
    must have LOCAL_MODULE and LOCAL_SRC_FILES defined, at a minimum before
    including this file. Example usage:

      include $(BUILD_SHARED_LIBRARY)

    note that this will generate a file named lib$(LOCAL_MODULE).so

    A variant of BUILD_SHARED_LIBRARY that is used to build a target static
    library instead. Static libraries are not copied into your
    project/packages but can be used to build shared libraries (see
    Example usage:

      include $(BUILD_STATIC_LIBRARY)

    Note that this will generate a file named lib$(LOCAL_MODULE).a
不会被复制到project/packages中,但是可以被用来build shared libraries
    Points to a build script used to specify a prebuilt shared library.
    of LOCAL_SRC_FILES must be a single path to a prebuilt shared
    library (e.g. foo/libfoo.so), instead of a source file.

    You can reference the prebuilt library in another module using
    the LOCAL_PREBUILTS variable (see docs/PREBUILTS.html for more

    This is the same as PREBUILT_SHARED_LIBRARY, but for a static library
    file instead. See docs/PREBUILTS.html for more.

    Name of the target CPU architecture as it is specified by the
    full Android open-source build. This is 'arm' for any ARM-compatible
    build, independent of the CPU architecture revision.

    Name of the target Android platform when this Android.mk is parsed.
    For example, 'android-3' correspond to Android 1.5 system images. For
    a complete list of platform names and corresponding Android system
    images, read docs/STABLE-APIS.html.

    Name of the target CPU+ABI when this Android.mk is parsed.
    Two values are supported at the moment:

            For ARMv5TE


    NOTE: Up to Android NDK 1.6_r1, this variable was simply defined
          as 'arm'. However, the value has been redefined to better
          match what is used internally by the Android platform.

    For more details about architecture ABIs and corresponding
    compatibility issues, please read docs/CPU-ARCH-ABIS.html

    Other target ABIs will be introduced in future releases of the NDK
    and will have a different name. Note that all ARM-based ABIs will
    have 'TARGET_ARCH' defined to 'arm', but may have different

    The concatenation of target platform and ABI, it really is defined
    as $(TARGET_PLATFORM)-$(TARGET_ARCH_ABI) and is useful when you want
    to test against a specific target system image for a real device.

    By default, this will be 'android-3-armeabi'

    (Up to Android NDK 1.6_r1, this used to be 'android-3-arm' by default)
NDK-provided function macros:
- - - - - - - - - - - - - - -

The following are GNU Make 'function' macros, and must be evaluated
by using '$(call <function>)'. They return textual information.

    Returns the path of the last included Makefile, which typically is
    the current Android.mk's directory. This is useful to define
    LOCAL_PATH at the start of your Android.mk as with:

        LOCAL_PATH := $(call my-dir)

    IMPORTANT NOTE: Due to the way GNU Make works, this really returns
    the path of the *last* *included* *Makefile* during the parsing of
    build scripts. Do not call my-dir after including another file.
    For example, consider the following example:

        LOCAL_PATH := $(call my-dir)

        ... declare one module

        include $(LOCAL_PATH)/foo/Android.mk

        LOCAL_PATH := $(call my-dir)

        ... declare another module

    The problem here is that the second call to 'my-dir' will define
    LOCAL_PATH to $PATH/foo instead of $PATH, due to the include that
    was performed before that.

    For this reason, it's better to put additional includes after
    everything else in an Android.mk, as in:

        LOCAL_PATH := $(call my-dir)

        ... declare one module

        LOCAL_PATH := $(call my-dir)

        ... declare another module

        # extra includes at the end of the Android.mk
        include $(LOCAL_PATH)/foo/Android.mk

    If this is not convenient, save the value of the first my-dir call
    into another variable, for example:

        MY_LOCAL_PATH := $(call my-dir)


        ... declare one module

        include $(LOCAL_PATH)/foo/Android.mk


        ... declare another module

    Returns a list of Android.mk located in all sub-directories of
    the current 'my-dir' path. For example, consider the following


    If sources/foo/Android.mk contains the single line:

        include $(call all-subdir-makefiles)

    Then it will include automatically sources/foo/lib1/Android.mk and

    This function can be used to provide deep-nested source directory
    hierarchies to the build system. Note that by default, the NDK
    will only look for files in sources/*/Android.mk

    Returns the path of the current Makefile (i.e. where the function
    is called).

    Returns the path of the parent Makefile in the inclusion tree,
    i.e. the path of the Makefile that included the current one.

    Guess what...

    A function that allows you to find and include the Android.mk
    of another module by name. A typical example is:

      $(call import-module,<name>)

    And this will look for the module tagged <name> in the list of
    directories referenced by your NDK_MODULE_PATH environment
    variable, and include its Android.mk automatically for you.

    Read docs/IMPORT-MODULE.html for more details.
Module-description variables:
- - - - - - - - - - - - - - -

The following variables are used to describe your module to the build
system. You should define some of them between an 'include $(CLEAR_VARS)'
and an 'include $(BUILD_XXXXX)'. As written previously, $(CLEAR_VARS) is
a script that will undefine/clear all of these variables, unless explicitly
noted in their description.

    This variable is used to give the path of the current file.
    You MUST define it at the start of your Android.mk, which can
    be done with:

      LOCAL_PATH := $(call my-dir)

    This variable is *not* cleared by $(CLEAR_VARS) so only one
    definition per Android.mk is needed (in case you define several
    modules in a single file).

    This is the name of your module. It must be unique among all
    module names, and shall not contain any space. You MUST define
    it before including any $(BUILD_XXXX) script.

    By default, the module name determines the name of generated files,
    e.g. lib<foo>.so for a shared library module named <foo>. However
    you should only refer to other modules with their 'normal'
    name (e.g. <foo>) in your NDK build files (either Android.mk
    or Application.mk)

    You can override this default with LOCAL_MODULE_FILENAME (see below)

    This variable is optional, and allows you to redefine the name of
    generated files. By default, module <foo> will always generate a
    static library named lib<foo>.a or a shared library named lib<foo>.so,
    which are standard Unix conventions.

    You can override this by defining LOCAL_MODULE_FILENAME, For example:

        LOCAL_MODULE := foo-version-1
        LOCAL_MODULE_FILENAME := libfoo

    NOTE: You should not put a path or file extension in your
    LOCAL_MODULE_FILENAME, these will be handled automatically by the
    build system.

    This is a list of source files that will be built for your module.
    Only list the files that will be passed to a compiler, since the
    build system automatically computes dependencies for you.

    Note that source files names are all relative to LOCAL_PATH and
    you can use path components, e.g.:

      LOCAL_SRC_FILES := foo.c \

    NOTE: Always use Unix-style forward slashes (/) in build files.
          Windows-style back-slashes will not be handled properly.

    This is an optional variable that can be defined to indicate
    the file extension(s) of C++ source files. They must begin with a dot.
    The default is '.cpp' but you can change it. For example:

        LOCAL_CPP_EXTENSION := .cxx

    Since NDK r7, you can list several extensions in this variable, as in:

        LOCAL_CPP_EXTENSION := .cxx .cpp .cc

    This is an optional variable that can be defined to indicate
    that your code relies on specific C++ features. To indicate that
    your code uses RTTI (RunTime Type Information), use the following:

        LOCAL_CPP_FEATURES := rtti

    To indicate that your code uses C++ exceptions, use:

        LOCAL_CPP_FEATURES := exceptions

    You can also use both of them with (order is not important):

        LOCAL_CPP_FEATURES := rtti features

    The effect of this variable is to enable the right compiler/linker
    flags when building your modules from sources. For prebuilt binaries,
    this also helps declare which features the binary relies on to ensure
    the final link works correctly.

    It is recommended to use this variable instead of enabling -frtti and
    -fexceptions directly in your LOCAL_CPPFLAGS definition.

    An optional list of paths, relative to the NDK *root* directory,
    which will be appended to the include search path when compiling
    all sources (C, C++ and Assembly). For example:

        LOCAL_C_INCLUDES := sources/foo

    Or even:

        LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo

    These are placed before any corresponding inclusion flag in

    The LOCAL_C_INCLUDES path are also used automatically when
    launching native debugging with ndk-gdb.

    An optional set of compiler flags that will be passed when building
    C *and* C++ source files.

    This can be useful to specify additional macro definitions or
    compile options.

    IMPORTANT: Try not to change the optimization/debugging level in
               your Android.mk, this can be handled automatically for
               you by specifying the appropriate information in
               your Application.mk, and will let the NDK generate
               useful data files used during debugging.

    NOTE: In android-ndk-1.5_r1, the corresponding flags only applied
          to C source files, not C++ ones. This has been corrected to
          match the full Android build system behaviour. (You can use
          LOCAL_CPPFLAGS to specify flags for C++ sources only now).

    It is possible to specify additional include paths with
    LOCAL_CFLAGS += -I<path>, however, it is better to use LOCAL_C_INCLUDES
    for this, since the paths will then also be used during native
    debugging with ndk-gdb.

    An alias for LOCAL_CPPFLAGS. Note that use of this flag is obsolete
    as it may disappear in future releases of the NDK.

    An optional set of compiler flags that will be passed when building
    C++ source files *only*. They will appear after the LOCAL_CFLAGS
    on the compiler's command-line.

    NOTE: In android-ndk-1.5_r1, the corresponding flags applied to
          both C and C++ sources. This has been corrected to match the
          full Android build system. (You can use LOCAL_CFLAGS to specify
          flags for both C and C++ sources now).

    The list of static libraries modules (built with BUILD_STATIC_LIBRARY)
    that should be linked to this module. This only makes sense in
    shared library modules.

    The list of shared libraries *modules* this module depends on at runtime.
    This is necessary at link time and to embed the corresponding information
    in the generated file.

    A variant of LOCAL_STATIC_LIBRARIES used to express that the corresponding
    library module should be used as "whole archives" to the linker. See the
    GNU linker's documentation for the --whole-archive flag.

    This is generally useful when there are circular dependencies between
    several static libraries. Note that when used to build a shared library,
    this will force all object files from your whole static libraries to be
    added to the final binary. This is not true when generating executables

    The list of additional linker flags to be used when building your
    module. This is useful to pass the name of specific system libraries
    with the "-l" prefix. For example, the following will tell the linker
    to generate a module that links to /system/lib/libz.so at load time:

      LOCAL_LDLIBS := -lz

    See docs/STABLE-APIS.html for the list of exposed system libraries you
    can linked against with this NDK release.

    By default, any undefined reference encountered when trying to build
    a shared library will result in an "undefined symbol" error. This is a
    great help to catch bugs in your source code.

    However, if for some reason you need to disable this check, set this
    variable to 'true'. Note that the corresponding shared library may fail
    to load at runtime.

    By default, ARM target binaries will be generated in 'thumb' mode, where
    each instruction are 16-bit wide. You can define this variable to 'arm'
    if you want to force the generation of the module's object files in
    'arm' (32-bit instructions) mode. E.g.:

      LOCAL_ARM_MODE := arm

    Note that you can also instruct the build system to only build specific
    sources in ARM mode by appending an '.arm' suffix to its source file
    name. For example, with:

       LOCAL_SRC_FILES := foo.c bar.c.arm

    Tells the build system to always compile 'bar.c' in ARM mode, and to
    build foo.c according to the value of LOCAL_ARM_MODE.

    NOTE: Setting APP_OPTIM to 'debug' in your Application.mk will also force
          the generation of ARM binaries as well. This is due to bugs in the
          toolchain debugger that don't deal too well with thumb code.

    Defining this variable to 'true' allows the use of ARM Advanced SIMD
    (a.k.a. NEON) GCC intrinsics in your C and C++ sources, as well as
    NEON instructions in Assembly files.

    You should only define it when targeting the 'armeabi-v7a' ABI that
    corresponds to the ARMv7 instruction set. Note that not all ARMv7
    based CPUs support the NEON instruction set extensions and that you
    should perform runtime detection to be able to use this code at runtime
    safely. To learn more about this, please read the documentation at
    docs/CPU-ARM-NEON.html and docs/CPU-FEATURES.html.

    Alternatively, you can also specify that only specific source files
    may be compiled with NEON support by using the '.neon' suffix, as

        LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon

    In this example, 'foo.c' will be compiled in thumb+neon mode,
    'bar.c' will be compiled in 'thumb' mode, and 'zoo.c' will be
    compiled in 'arm+neon' mode.

    Note that the '.neon' suffix must appear after the '.arm' suffix
    if you use both (i.e. foo.c.arm.neon works, but not foo.c.neon.arm !)

    Android NDK r4 added support for the "NX bit" security feature.
    It is enabled by default, but you can disable it if you *really*
    need to by setting this variable to 'true'.

    NOTE: This feature does not modify the ABI and is only enabled on
          kernels targeting ARMv6+ CPU devices. Machine code generated
          with this feature enabled will run unmodified on devices
          running earlier CPU architectures.

    For more information, see:


    Define this variable to record a set of C/C++ compiler flags that will
    be added to the LOCAL_CFLAGS definition of any other module that uses

    For example, consider the module 'foo' with the following definition:

        include $(CLEAR_VARS)
        LOCAL_MODULE := foo
        LOCAL_SRC_FILES := foo/foo.c
        include $(BUILD_STATIC_LIBRARY)

    And another module, named 'bar' that depends on it as:

        include $(CLEAR_VARS)
        LOCAL_MODULE := bar
        LOCAL_SRC_FILES := bar.c
        LOCAL_CFLAGS := -DBAR=2
        include $(BUILD_SHARED_LIBRARY)

    Then, the flags '-DFOO=1 -DBAR=2' will be passed to the compiler when
    building bar.c

    Exported flags are prepended to your module's LOCAL_CFLAGS so you can
    easily override them. They are also transitive: if 'zoo' depends on
    'bar' which depends on 'foo', then 'zoo' will also inherit all flags
    exported by 'foo'.

    Finally, exported flags are *not* used when building the module that
    exports them. In the above example, -DFOO=1 would not be passed to the
    compiler when building foo/foo.c.

    Same as LOCAL_EXPORT_CFLAGS, but for C++ flags only.

    Same as LOCAL_EXPORT_CFLAGS, but for C include paths.
    This can be useful if 'bar.c' wants to include headers
    that are provided by module 'foo'.

    Same as LOCAL_EXPORT_CFLAGS, but for linker flags. Note that the
    imported linker flags will be appended to your module's LOCAL_LDLIBS
    though, due to the way Unix linkers work.

    This is typically useful when module 'foo' is a static library and has
    code that depends on a system library. LOCAL_EXPORT_LDLIBS can then be
    used to export the dependency. For example:

        include $(CLEAR_VARS)
        LOCAL_MODULE := foo
        LOCAL_SRC_FILES := foo/foo.c
        LOCAL_EXPORT_LDLIBS := -llog
        include $(BUILD_STATIC_LIBRARY)

        include $(CLEAR_VARS)
        LOCAL_MODULE := bar
        LOCAL_SRC_FILES := bar.c
        include $(BUILD_SHARED_LIBRARY)

    There, libbar.so will be built with a -llog at the end of the linker
    command to indicate that it depends on the system logging library,
    because it depends on 'foo'.

    Define this variable to a shell command that will be used to filter
    the assembly files from, or generated from, your LOCAL_SRC_FILES.

    When it is defined, the following happens:

      - Any C or C++ source file is generated into a temporary assembly
        file (instead of being compiled into an object file).

      - Any temporary assembly file, and any assembly file listed in
        LOCAL_SRC_FILES is sent through the LOCAL_FILTER_ASM command
        to generate _another_ temporary assembly file.

      - These filtered assembly files are compiled into object file.

    In other words, If you have:

      LOCAL_SRC_FILES  := foo.c bar.S
      LOCAL_FILTER_ASM := myasmfilter

    foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.o
    bar.S                                 --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o

    Were "1" corresponds to the compiler, "2" to the filter, and "3" to the
    assembler. The filter must be a standalone shell command that takes the
    name of the input file as its first argument, and the name of the output
    file as the second one, as in:

        myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
        myasmfilter bar.S $OBJS_DIR/bar.S


SDK中添加docs文件 首先介绍一下docs docs这里面是Android SDK API参考文档,所有的API都可以在这里查询到 如果SDK中没有docs文件以下步骤可以添加 1.首先打...
  • CodeFarmerCXY
  • CodeFarmerCXY
  • 2017年03月06日 10:08
  • 967

使用spring rest docs 进行单元测试

使用spring rest dosc进行单元测试
  • Amethyst128
  • Amethyst128
  • 2017年06月06日 17:03
  • 769


今天看着教材和韩顺平的视频自己动手配置虚拟主机。结果我完全原原本本的一字不差的按照韩老师和网上博客修改配置,结果连Apache都启动不了了,真是日了狗了。 没办法我就又去找APACHE官网看文档,也是...
  • abel004
  • abel004
  • 2015年06月25日 10:37
  • 544

[Elasticsearch] 控制相关度 (一) - 相关度分值计算背后的理论

本章翻译自Elasticsearch官方指南的Controlling Relevance一章。 控制相关度(Controlling Relevance) 对于仅处理结构化数...
  • dm_vincent
  • dm_vincent
  • 2014年12月23日 10:02
  • 19752

解决Android SDK的离线文档(Docs)加载速度慢问题

原文:http://my.oschina.net/willedward/blog/91260 sdk下载的android 离线文档加载速度很慢 ,查找了一些资料发现可以通过设置浏览器脱机工作解决, ...
  • yaocai321
  • yaocai321
  • 2015年04月14日 21:16
  • 3014


1. 盘符的切换      如 切换到d盘 d:2. 展示文件夹下的所有文件和文件夹      dir3. 创建文件夹       md 文件夹名称,如:md filename4. 创建文件     ...
  • u013384788
  • u013384788
  • 2017年04月20日 16:40
  • 255


android进程间通信:使用AIDL 分类: android 2010-01-04 18:01 18238人阅读 评论(31) 收藏 举报       欢迎阅读本文,你能关注本文,你知道你...
  • shangyaowei
  • shangyaowei
  • 2013年12月19日 20:40
  • 224


电脑上已经装好了wamp,但是windows下默认不会安装pear,所以去网上找了一些资料进行安装,下面就是一些记录笔记。 1.下载PEAR并进行前期准备 下载地址:http://pear...
  • yongzhen150
  • yongzhen150
  • 2017年12月02日 12:16
  • 55

使用 Github Pages 发布你的项目文档

你可能比较熟悉如何用 Github Pages 来分享你的工作,又或许你看过一堂教你建立你的第一个 Github Pages 网站的教程。近期 Github Pages 的改进使得从不同的数据源来发布...
  • u014743697
  • u014743697
  • 2016年10月02日 10:24
  • 736

SpringBoot非官方教程 | 第十篇: 用spring Restdocs创建API文档

这篇文章将带你了解如何用spring官方推荐的restdoc去生成api文档。本文创建一个简单的springboot工程,将http接口通过Api文档暴露出来。只需要通过 JUnit单元测试和Spri...
  • forezp
  • forezp
  • 2017年04月30日 16:08
  • 27138