Bug#200003: Any progress?
tag 23 patch thanks dude On Sat, Jan 07, 2006, Matthias Klose wrote: I do not intend to work on it until summer, when it becomes clear which compiler versions are included in etch. maybe these are 2.95, 3.4 and 4.1. who knows ... I'm happy to include any patches before that, if you are volunteering ;-) Some things are already prepared in the packaging. Hi Matthias, and thanks for the time you're spending on gcc's and python's transitions! Now that we know gcc 4.1 is going to be the default version in Etch, maybe it is time to get rid of this old bug. Here is a cpp.1 based on the help output of cpp (and on the help2man command) that may be considered as a free interim replacement until we have an exhaustive free documentation for GCC. Do you think it will help? Do you want me to work on other manpages from the --help output? I can imagine that you are very busy currently, but please just drop a note to let me know if I can work on it during the current BSP in Paris. Regards, -- adn Mohammed Adnène Trojette .TH CPP 1 2006-06-04 gcc-4.1.2 GNU .SH NAME cpp \- The C Preprocessor .SH SYNOPSIS .B cpp [\fIoptions\fR] \fIfile\fR... .SH OPTIONS .TP \fB\-pass\-exit\-codes\fR Exit with highest error code from a phase .TP \fB\-\-help\fR Display this information .TP \fB\-\-target\-help\fR Display target specific command line options .IP (Use '\-v \fB\-\-help\fR' to display command line options of sub\-processes) .TP \fB\-dumpspecs Display all of the built in spec strings .TP \fB\-dumpversion Display the version of the compiler .TP \fB\-dumpmachine Display the compiler's target processor .TP \fB\-print\-search\-dirs Display the directories in the compiler's search path .TP \fB\-print\-libgcc\-file\-name Display the name of the compiler's companion library .TP \fB\-print\-file\-name=lib Display the full path to library lib .TP \fB\-print\-prog\-name=prog Display the full path to compiler component prog .TP \fB\-print\-multi\-directory Display the root directory for versions of libgcc .TP \fB\-print\-multi\-lib Display the mapping between command line options and .IP multiple library search directories .HP \fB\-print\-multi\-os\-directory\fR Display the relative path to OS libraries .TP \fB\-Wa\fR,options Pass comma\-separated options on to the assembler .TP \fB\-Wp\fR,options Pass comma\-separated options on to the preprocessor .TP \fB\-Wl\fR,options Pass comma\-separated options on to the linker .TP \fB\-Xassembler\fR arg Pass arg on to the assembler .TP \fB\-Xpreprocessor\fR arg Pass arg on to the preprocessor .TP \fB\-Xlinker\fR arg Pass arg on to the linker .TP \fB\-combine\fR Pass multiple source files to compiler at once .TP \fB\-save\-temps\fR Do not delete intermediate files .TP \fB\-pipe\fR Use pipes rather than intermediate files .TP \fB\-time\fR Time the execution of each subprocess .TP \fB\-specs=\fRfile Override built\-in specs with the contents of file .TP \fB\-std=\fRstandard Assume that the input sources are for standard .TP \fB\-\-sysroot=\fRdirectory Use directory as the root directory for headers for headers and libraries .TP \fB\-B\fR directory Add directory to the compiler's search paths .TP \fB\-b\fR machine Run gcc for target machine, if installed .TP \fB\-V\fR version Run gcc version number version, if installed .TP \fB\-v\fR Display the programs invoked by the compiler .TP \-### Like \fB\-v\fR but options quoted and commands not executed .TP \fB\-E\fR Preprocess only; do not compile, assemble or link .TP \fB\-S\fR Compile only; do not assemble or link .TP \fB\-c\fR Compile and assemble, but do not link .TP \fB\-o\fR file Place the output into file .TP \fB\-x\fR language Specify the language of the following input files Permissible languages include: c c++ assembler none \'none' means revert to the default behavior of guessing the language based on the file's extension .PP Options starting with \fB\-g\fR, \fB\-f\fR, \fB\-m\fR, \fB\-O\fR, \fB\-W\fR, or \fB\-\-param\fR are automatically passed on to the various sub\-processes invoked by cpp. In order to pass other options on to these processes the \fB\-W\fRletter options must be used. .PP For bug reporting instructions, please see: URL:http://gcc.gnu.org/bugs.html. For Debian GNU/Linux specific bug reporting instructions, please see: URL:file:///usr/share/doc/gcc\-4.1/README.Bugs. .SH COPYRIGHT Copyright \(co 2006 Free Software Foundation, Inc. .br This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. .SH SEE ALSO The full documentation for .B cpp is maintained as a Texinfo manual. If the .B info and .B cpp programs are properly installed at your site, the command .IP .B info cpp .PP should give you access to the complete manual.
Bug#200003: Any progress?
tags 23 - patch thanks Mohammed Adnène Trojette writes: tag 23 patch thanks dude On Sat, Jan 07, 2006, Matthias Klose wrote: I do not intend to work on it until summer, when it becomes clear which compiler versions are included in etch. maybe these are 2.95, 3.4 and 4.1. who knows ... I'm happy to include any patches before that, if you are volunteering ;-) Some things are already prepared in the packaging. Now that we know gcc 4.1 is going to be the default version in Etch, maybe it is time to get rid of this old bug. Here is a cpp.1 based on the help output of cpp (and on the help2man command) that may be considered as a free interim replacement until we have an exhaustive free documentation for GCC. Do you think it will help? Do you want me to work on other manpages from the --help output? Mohammed, thanks for your help. It's certainly valueable to have manual pages in main. If you do want to go this way, we need replacements for _all_ manual pages. The second thing is to remove the gfdl'd texi files from the sources, so that the package still builds. The idea is to replace these files with dummy content, such that the build still succeds and the Makefile don't have to be patched. The files in question are in: gcc/doc/* gcc/doc/include/* gcc/gfortran/gfortran.texi gcc/java/gcj.texi gcc/ada/gnat-style.texi gcc/ada/gnat_rm.texi gcc/ada/gnat_ugn.texi gcc/fortran/invoke.texi gcc/fortran/intrinsic.texi gcc/fortran/gfortran.texi gcc/treelang/treelang.texi libstdc++-v3/docs/html/17_intro/porting.texi libiberty/*.texi Most of the files in gcc/doc/, gcc/doc/include/, libiberty/ can be replaced by en empty file (or better having just a comment). The man pages are generated from some texi files, so there must be some infrastructure kept (see gcc/java/gcj.texi to start with the worst one). Of course you could write your new manual pages as texi documents as well. A patch should be a tarball of all these new files. Matthias
Bug#200003: Any progress?
Matthias Klose [EMAIL PROTECTED] writes: The second thing is to remove the gfdl'd texi files from the sources, so that the package still builds. The idea is to replace these files with dummy content, such that the build still succeds and the Makefile don't have to be patched. Unless I am mistaken, there was a Debian General Resolution lately that allows GFDL'd documents in main, provided they have no front-cover text, no back-cover text and no invariants. I am concerned that wholesale deletion of all documentation from the GCC package is a disservice to users. Should we not rather assess each document individually and remove only those that fail the General Resolution criteria? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#200003: Any progress?
On Sat, Jun 10, 2006, Ludovic Brenta wrote: Unless I am mistaken, there was a Debian General Resolution lately that allows GFDL'd documents in main, provided they have no front-cover text, no back-cover text and no invariants. I am concerned that wholesale deletion of all documentation from the GCC package is a disservice to users. Should we not rather assess each document individually and remove only those that fail the General Resolution criteria? All of them actually front and back cover texts, as far as I am reading right now in the texi files. Don't forget the documentation will be available in non-free as soon as a package is ready. And don't be afraid, we won't be throwing out of main DFSG free documentation ;) -- adn Mohammed Adnène Trojette
Bug#200003: Any progress?
Ludovic Brenta writes: Matthias Klose [EMAIL PROTECTED] writes: The second thing is to remove the gfdl'd texi files from the sources, so that the package still builds. The idea is to replace these files with dummy content, such that the build still succeds and the Makefile don't have to be patched. Unless I am mistaken, there was a Debian General Resolution lately that allows GFDL'd documents in main, provided they have no front-cover text, no back-cover text and no invariants. I am concerned that wholesale deletion of all documentation from the GCC package is a disservice to users. Should we not rather assess each document individually and remove only those that fail the General Resolution criteria? sure, are there any? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#200003: Any progress?
Matthias Klose wrote:
anyway, I'll wait until Debian's position on the GFDL is documented
somewhere and then address all these together.
It's pretty well documented by now. So is it time? :-P
I'm sorry I haven't had the time or mental focus to write replacement
manpages, but the {cpp, gcc, g++} --help output is actually fairly extensive
and would be a good interim solution.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#200003: Any progress?
Nathanael Nerode writes:
Matthias Klose wrote:
anyway, I'll wait until Debian's position on the GFDL is documented
somewhere and then address all these together.
It's pretty well documented by now. So is it time? :-P
I'm sorry I haven't had the time or mental focus to write replacement
manpages, but the {cpp, gcc, g++} --help output is actually fairly extensive
and would be a good interim solution.
I do not intend to work on it until summer, when it becomes clear
which compiler versions are included in etch. maybe these are 2.95,
3.4 and 4.1. who knows ...
I'm happy to include any patches before that, if you are volunteering
;-) Some things are already prepared in the packaging.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
