In the usual case where Autoconf is creating a @file{config.h} file,
you should include @file{config.h} first, before any other include
file. That way, for example, if @file{config.h} defines
-@samp{restrict} to be the empty string on a pre-C99 host, the
-definition is consistent for all include files.
-
-You should include Gnulib-provided headers before system headers,
-so that Gnulib-provided headers can adjust how a system header
-behaves.
+@samp{restrict} to be the empty string on a pre-C99 host, or a macro
+like @samp{_FILE_OFFSET_BITS} that affects the layout of data
+structures, the definition is consistent for all include files.
+Also, on some platforms macros like @samp{_FILE_OFFSET_BITS} and
+@samp{_GNU_SOURCE} may be ineffective, or may have only a limited
+effect, if defined after the first system header file is included.
A final word of warning: Gnulib currently assumes it will be
responsible for @emph{all} functions that end up in the Autoconf
should be treated like generated source files, like for example a
@file{parser.c} file is generated from @file{parser.y}.
+@itemize
+
+@item
In projects which commit all source files, whether generated or not, into
CVS, the @code{gnulib-tool} generated files should all be committed.
+Gnulib also contains files generated by @command{make} (and removed by
+@code{make clean}, using information determined by @command{configure}
+They should not be checked into CVS, but instead added to
+@file{.cvsignore}. When you have a Gnulib source file of the form
+@file{lib/foo_.h}, the corresponding @file{lib/foo.h} is such a file.
+
+
+@item
In projects which customarily omit from the CVS all files that generated
from other source files, all these files and directories would not be
added into CVS. The only file that must be added to CVS is
but it does not offer the possibility to change the way Gnulib is used.
Also it does not report in the ChangeLogs the files that it had to add
because they were missing.
+
+@end itemize