mcu
/
libopencm3
mirror of https://github.com/libopencm3/libopencm3.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
2306 Commits
2 Branches
1 Tag
21 MiB
Tree: ebe8c4a66c
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'ebe8c4a66c'
${ noResults }
libopencm3/doc/Makefile

55 lines
1.8 KiB
Raw Normal View History

Setup to document entire project using doxygen. New doc directory with config files and generated html, LaTeX/pdf. Makefile provided for autogeneration and explanatory README. The project structure is hostile to doxygen, which can't cope with functions of the same name. Doxygen is run for each family separately, and separately for LaTeX generation. Customized layout files sort of "integrate" HTML, and separate pdfs are generated for each family. Not ideal but seems the best solution until doxygen changes, if at all.
12 years ago
# Makefile to build libopencm3 documentation
# 14 September 2012
# (C) Ken Sarkies <ksarkies@internode.on.net>
[stm32f7] Add initial support of the family, GPIO support. Most changes are noise from doxygen. Readme udpated to explain newer FP_FLAGS for m7 stm32f7 library is skipped if the toolchain doesn&#39;t support it yet.
10 years ago
ARCHS := stm32f0 stm32f1 stm32f2 stm32f3 stm32f4 stm32f7
stm32l4: Add to documentation build Don&#39;t include any of the common files yet, we&#39;re only getting a stub framework up for further work. This is mostly noise adding links from the other families to make the l4 &#34;exist&#34;
9 years ago
ARCHS += stm32l0 stm32l1 stm32l4
efm32hg: add basic makefile, interrupts, device information
7 years ago
ARCHS += efm32g efm32gg efm32hg efm32lg efm32tg
doc: msp432/e4: hook up doxygen generation Just hooks up the target, no changes to the submitted documentation.
6 years ago
ARCHS += lm3s lm4f msp432e4
[Doxygen] Strip out architectures from Makefile dependencies This commit shrinks the Makefile of the doxygen and makes easy error-prone addition of the new supported platforms. The user should modify only one line at start of file to add new supported family to the build process. The calling format is preserved and is compatible with old version of the makefile.
10 years ago
ARCHS += lpc13xx lpc17xx lpc43xx
ARCHS += sam3a sam3n sam3s sam3u sam3x
ARCHS += vf6xx
doc: drop latex support HTML output is good enough for anyone, and is less maintennance.
7 years ago
doc: html
Setup to document entire project using doxygen. New doc directory with config files and generated html, LaTeX/pdf. Makefile provided for autogeneration and explanatory README. The project structure is hostile to doxygen, which can&#39;t cope with functions of the same name. Doxygen is run for each family separately, and separately for LaTeX generation. Customized layout files sort of &#34;integrate&#34; HTML, and separate pdfs are generated for each family. Not ideal but seems the best solution until doxygen changes, if at all.
12 years ago
doc: drop the standalone cm3/usb documents They are now included in the projects, so each .a file has a standalone complete package of all documentation.
7 years ago
html: rebuildsources $(ARCHS)
[Doxygen] Strip out architectures from Makefile dependencies This commit shrinks the Makefile of the doxygen and makes easy error-prone addition of the new supported platforms. The user should modify only one line at start of file to add new supported family to the build process. The calling format is preserved and is compatible with old version of the makefile.
10 years ago
doxygen
$(ARCHS):
cd $@/; doxygen
[sam3] show the sam3 subfamilies in the doxygen-generated documentation
11 years ago
Setup to document entire project using doxygen. New doc directory with config files and generated html, LaTeX/pdf. Makefile provided for autogeneration and explanatory README. The project structure is hostile to doxygen, which can&#39;t cope with functions of the same name. Doxygen is run for each family separately, and separately for LaTeX generation. Customized layout files sort of &#34;integrate&#34; HTML, and separate pdfs are generated for each family. Not ideal but seems the best solution until doxygen changes, if at all.
12 years ago
clean:
doc: mk: remove generated files on clean
7 years ago
@rm -rf html/ */html/ */*.tag */doxy.sourcelist */doxygen_*.log
Setup to document entire project using doxygen. New doc directory with config files and generated html, LaTeX/pdf. Makefile provided for autogeneration and explanatory README. The project structure is hostile to doxygen, which can&#39;t cope with functions of the same name. Doxygen is run for each family separately, and separately for LaTeX generation. Customized layout files sort of &#34;integrate&#34; HTML, and separate pdfs are generated for each family. Not ideal but seems the best solution until doxygen changes, if at all.
12 years ago
doc: dynamically generate correct file lists Instead of the fragile and error prone attempts to specifically include/exclude files from doxygen by name and pattern, simply use the already generated .d files to provide accurate and up to date lists of all source files used. Pros: * Nothing left to worry about * Much more encouraging to actually _work_ on the documentation now that you can be sure the right docs will be generated instead of a confusing mix. Downsides/Upsides: * Automatically includes all CM3/USB in each device&#39;s page _as well_ now Downsides: * lpc43xx still manually listed. However, completely contained in it&#39;s own dir, so no problems * No attempt to carry this in latex. easy, but more tempted to drop latex support outright. (I don&#39;t think the generation there has even worked for a while now) * Due to the mismatch between lib directories and document roots, the sourcelist can&#39;t be magically created per directory. There has to be some sort of mapping between the two, so as this is doc generation only, a static list seems sane for maintennance. (Especially compared to the old method) * Source list generation probably doesn&#39;t work on windows.
7 years ago
rebuildsources:
@printf "Manually regenerating source lists from build deps\n"
../scripts/gendoxylist ../lib/stm32/f0 stm32f0
../scripts/gendoxylist ../lib/stm32/f1 stm32f1
../scripts/gendoxylist ../lib/stm32/f2 stm32f2
../scripts/gendoxylist ../lib/stm32/f3 stm32f3
../scripts/gendoxylist ../lib/stm32/f4 stm32f4
../scripts/gendoxylist ../lib/stm32/f7 stm32f7
../scripts/gendoxylist ../lib/stm32/l0 stm32l0
../scripts/gendoxylist ../lib/stm32/l1 stm32l1
../scripts/gendoxylist ../lib/stm32/l4 stm32l4
../scripts/gendoxylist ../lib/efm32/g efm32g
../scripts/gendoxylist ../lib/efm32/gg efm32gg
efm32hg: add basic makefile, interrupts, device information
7 years ago
../scripts/gendoxylist ../lib/efm32/hg efm32hg
doc: dynamically generate correct file lists Instead of the fragile and error prone attempts to specifically include/exclude files from doxygen by name and pattern, simply use the already generated .d files to provide accurate and up to date lists of all source files used. Pros: * Nothing left to worry about * Much more encouraging to actually _work_ on the documentation now that you can be sure the right docs will be generated instead of a confusing mix. Downsides/Upsides: * Automatically includes all CM3/USB in each device&#39;s page _as well_ now Downsides: * lpc43xx still manually listed. However, completely contained in it&#39;s own dir, so no problems * No attempt to carry this in latex. easy, but more tempted to drop latex support outright. (I don&#39;t think the generation there has even worked for a while now) * Due to the mismatch between lib directories and document roots, the sourcelist can&#39;t be magically created per directory. There has to be some sort of mapping between the two, so as this is doc generation only, a static list seems sane for maintennance. (Especially compared to the old method) * Source list generation probably doesn&#39;t work on windows.
7 years ago
../scripts/gendoxylist ../lib/efm32/lg efm32lg
../scripts/gendoxylist ../lib/efm32/tg efm32tg
../scripts/gendoxylist ../lib/lm3s lm3s
../scripts/gendoxylist ../lib/lm4f lm4f
doc: msp432/e4: hook up doxygen generation Just hooks up the target, no changes to the submitted documentation.
6 years ago
../scripts/gendoxylist ../lib/msp432/e4 msp432e4
doc: dynamically generate correct file lists Instead of the fragile and error prone attempts to specifically include/exclude files from doxygen by name and pattern, simply use the already generated .d files to provide accurate and up to date lists of all source files used. Pros: * Nothing left to worry about * Much more encouraging to actually _work_ on the documentation now that you can be sure the right docs will be generated instead of a confusing mix. Downsides/Upsides: * Automatically includes all CM3/USB in each device&#39;s page _as well_ now Downsides: * lpc43xx still manually listed. However, completely contained in it&#39;s own dir, so no problems * No attempt to carry this in latex. easy, but more tempted to drop latex support outright. (I don&#39;t think the generation there has even worked for a while now) * Due to the mismatch between lib directories and document roots, the sourcelist can&#39;t be magically created per directory. There has to be some sort of mapping between the two, so as this is doc generation only, a static list seems sane for maintennance. (Especially compared to the old method) * Source list generation probably doesn&#39;t work on windows.
7 years ago
../scripts/gendoxylist ../lib/lpc13xx lpc13xx
../scripts/gendoxylist ../lib/lpc17xx lpc17xx
../scripts/gendoxylist ../lib/sam/3a sam3a
../scripts/gendoxylist ../lib/sam/3n sam3n
../scripts/gendoxylist ../lib/sam/3s sam3s
../scripts/gendoxylist ../lib/sam/3u sam3u
../scripts/gendoxylist ../lib/sam/3x sam3x
../scripts/gendoxylist ../lib/vf6xx vf6xx
doc: drop latex support HTML output is good enough for anyone, and is less maintennance.
7 years ago
.PHONY: doc html $(ARCHS) rebuildsources
Setup to document entire project using doxygen. New doc directory with config files and generated html, LaTeX/pdf. Makefile provided for autogeneration and explanatory README. The project structure is hostile to doxygen, which can&#39;t cope with functions of the same name. Doxygen is run for each family separately, and separately for LaTeX generation. Customized layout files sort of &#34;integrate&#34; HTML, and separate pdfs are generated for each family. Not ideal but seems the best solution until doxygen changes, if at all.
12 years ago