diff options
| -rw-r--r-- | l10ntools/README | 5 | ||||
| -rw-r--r-- | lcms2/README | 3 | ||||
| -rw-r--r-- | m4/README | 2 | ||||
| -rw-r--r-- | more_fonts/README | 1 | ||||
| -rw-r--r-- | pango/README | 3 | ||||
| -rw-r--r-- | postgresql/README | 1 | ||||
| -rw-r--r-- | scp2/README | 1 | ||||
| -rw-r--r-- | setup_native/README | 6 | ||||
| -rw-r--r-- | soltools/README | 1 | ||||
| -rw-r--r-- | stlport/README | 1 | ||||
| -rw-r--r-- | test/README | 6 | ||||
| -rw-r--r-- | unotest/README | 1 | ||||
| -rw-r--r-- | vbahelper/README | 1 |
13 files changed, 32 insertions, 0 deletions
diff --git a/l10ntools/README b/l10ntools/README new file mode 100644 index 000000000000..192064aaf030 --- /dev/null +++ b/l10ntools/README @@ -0,0 +1,5 @@ +l10ntools is scanners module during gbuild'fication.
+l10ntools delivers some header files and scripts as well. To
+handle these, you should create two Packages, one for the headers and
+other for the scripts.
+l10ntools module has three lexer files
\ No newline at end of file diff --git a/lcms2/README b/lcms2/README new file mode 100644 index 000000000000..eb02e97cd791 --- /dev/null +++ b/lcms2/README @@ -0,0 +1,3 @@ +lcms2 (little cms engine)
+lcms2: Little cms is a small, speed optimized color management engine.
+with the new libcdr, writerperfect will depend on lcms2
\ No newline at end of file diff --git a/m4/README b/m4/README new file mode 100644 index 000000000000..a1fc6f61570e --- /dev/null +++ b/m4/README @@ -0,0 +1,2 @@ +m4 - Macros to locate and utilise pkg-config.
+work around m4 bracket stripping in MINGWSTRIP construction
\ No newline at end of file diff --git a/more_fonts/README b/more_fonts/README new file mode 100644 index 000000000000..6af7cf2d2a8a --- /dev/null +++ b/more_fonts/README @@ -0,0 +1 @@ +for adding or repacing fonts
\ No newline at end of file diff --git a/pango/README b/pango/README new file mode 100644 index 000000000000..75a73da2425e --- /dev/null +++ b/pango/README @@ -0,0 +1,3 @@ +Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most usage so far as been in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+ 2. Pango is designed to be modular; the core Pango layout can be used with four different font backends: Core X windowing system fonts, Client-side fonts on X using the Xft2 library, Direct rendering of scalable fonts using the FreeType library, Native fonts on Microsoft platforms. Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango-1.2 ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported.
+
+As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text.
\ No newline at end of file diff --git a/postgresql/README b/postgresql/README new file mode 100644 index 000000000000..c4d4f30b979b --- /dev/null +++ b/postgresql/README @@ -0,0 +1 @@ +PostgreSQL object-relational database management system
\ No newline at end of file diff --git a/scp2/README b/scp2/README new file mode 100644 index 000000000000..9274b445eef8 --- /dev/null +++ b/scp2/README @@ -0,0 +1 @@ +java accessibilty bridge cleanup
\ No newline at end of file diff --git a/setup_native/README b/setup_native/README new file mode 100644 index 000000000000..0da4570dc461 --- /dev/null +++ b/setup_native/README @@ -0,0 +1,6 @@ +To get one gbuild instance build only (tail_build only), migrating the "real"
+module should be the enough for a start. I assume extras, setup_native,
+readlicense not being depended upon by anything other than scp2 (so they could
+be run after tail_build for now). So bridges, soltools, sysui, cli_ure are the
+ones that should allow us to do a 'complete' gbuild-only build, if anyone is
+looking for the 'important' remaining modules.
\ No newline at end of file diff --git a/soltools/README b/soltools/README new file mode 100644 index 000000000000..3c56404e62b2 --- /dev/null +++ b/soltools/README @@ -0,0 +1 @@ +soltools: fix memory errors uncovered by valgrind and other tools.
\ No newline at end of file diff --git a/stlport/README b/stlport/README new file mode 100644 index 000000000000..8a23ae6e04a5 --- /dev/null +++ b/stlport/README @@ -0,0 +1 @@ +STLPort library for compatibility with old extensions for architectures where STLPort used to be used.
\ No newline at end of file diff --git a/test/README b/test/README new file mode 100644 index 000000000000..401f5d7e95f2 --- /dev/null +++ b/test/README @@ -0,0 +1,6 @@ +when you build, gdb will start with the cppunit test loaded, type "run" to execute the test under gdb.
+If you have consistent test failures on testCVEs, that probably means your antivirus is blocking the test files (as they are known to be exploits of fixed security issues). You may want to disable the monitoring of <root of repo>\*\pass in your AV.
+A top-level "make check" will first do a full build, then run all the subsequent tests, while a top-level "make subsequentcheck" will only run all the subsequent tests. You can run a single subsequent test via its target
+There will be a log file of the failed test, you can look at it with a text editor:
+workdir/unxlngx6/JunitTest/<module>_complex/done.log
+The log file will contain a Java stack trace of the failed test
\ No newline at end of file diff --git a/unotest/README b/unotest/README new file mode 100644 index 000000000000..11a50fb83e9c --- /dev/null +++ b/unotest/README @@ -0,0 +1 @@ +unotest: convert to gbuild
\ No newline at end of file diff --git a/vbahelper/README b/vbahelper/README new file mode 100644 index 000000000000..bf569d4cd915 --- /dev/null +++ b/vbahelper/README @@ -0,0 +1 @@ +Static helper functions for the VBA filters
\ No newline at end of file |