Re: [POLL] Change Gobo bootstrap scripts to CMake
Wolfgang Jansen <[email protected]> Wed, 23 Dec 2015 15:32:56 +0100
| Newsgroups | gmane.comp.lang.eiffel.gobo.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============8853579179109802242== Content-Type: multipart/alternative; boundary="------------000903080206080802090907" This is a multi-part message in MIME format. --------------000903080206080802090907 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtpa.mediabeam.com id tBNEWvj8000497 On 12/23/2015 07:38 AM, Eric Bezault wrote: > On 12/22/2015 19:42, CHAUVET Guillaume wrote: >> I hope one day GOBO will generate *.c *.h files per classes. By this >> way, we can enable ccache (natively supported by CMake 2.8.0) to detec= t >> what content files really change after C generation. > Note that it's not as easy as generating *.c and *.h files per classes. > Currently the Gobo compiler tries to optimize the C code generation by > performing a system level analysis of the Eiffel code. Which means that= , > unless you just change one character in one string, it is likely that > every C file would change after each compile. In order to be truly > incremental at the C level, the Gobo compiler should have another C > code generation mode which is more focused on preserving the C code > unmodified rather than on global optimization. This is the same thing > as in ISE's EiffelStudio with workbench (frozen) and finalize modes. > Currently the Gobo compiler only has the finalize mode. > Hi Eric, Guillaume, excuse when i drop into your discussion. Conceptually, splitting C code per class or type should not very hard: writing a type's struct or routine had to be enclosed into file-open,=20 file-close parentheses, one file per type. I see the problem at another level. Consider a large Eiffel system, e.g.=20 the GEC. It consists of about 2000 alive types (i.e. types where C code is to be=20 generated) from about 670 classes. Compilation may be per type or class=20 but linkage needs all file names in the command line. The Unix command=20 line allows after resolution of wildcards etc. for about 32000=20 characters (I do not know which restrictions Windows applies, if any).=20 So we have up to 16 characters for 2000 files, three charactersare=20 reserved: the dot, the extension 'c', the separating blank. This means=20 class or type names are in general too long and artificial file names=20 are to be generated like "gec1234.c". This is the way, EiffelStudio=20 tackles the problem: compilation of the many C files having cryptic=20 names in manageable chunks to intermediary object files and then linkage=20 of the much fewer objects. The problem for GEC would be to generate the=20 same file names for unchanged types/classes across various compilations,=20 since it was the intension to reuse all the unchanged C code.=20 EiffelStudio is an IDE, comparison of system states between forthcoming=20 compilations is duty of the project management, unchanged parts will be=20 detected and can be reused. So, the GEC had first to be upgraded to an ID= E. Taking all together, it is worth thinking again about C code generation=20 per type/class without turning GEC into an IDE. The true complication is=20 organizing the make utilities for compilation in chunks. The risk for=20 the user is to C-compile all the stuff if too many generated file names=20 changed, the gain for the user is much less C-compilation time if file=20 names were rather stable. Wolfgang --=20 Dr. Wolfgang Jansen Lauenburger Stra=DFe 40 D-12169 Berlin Tel: (+49) 0172 40 86 916 e-mail: [email protected] --------------000903080206080802090907 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtpa.mediabeam.com id tBNEWvj8000497 <html> <head> <meta content=3D"text/html; charset=3Dwindows-1252" http-equiv=3D"Content-Type"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> <div class=3D"moz-cite-prefix">On 12/23/2015 07:38 AM, Eric Bezault wrote:<br> </div> <blockquote cite=3D"mid:[email protected]" type=3D"cite"> <pre wrap=3D"">On 12/22/2015 19:42, CHAUVET Guillaume wrote: </pre> <blockquote type=3D"cite"> <pre wrap=3D"">I hope one day GOBO will generate *.c *.h files pe= r classes. By this way, we can enable ccache (natively supported by CMake 2.8.0) to detect what content files really change after C generation. </pre> </blockquote> <pre wrap=3D""> Note that it's not as easy as generating *.c and *.h files per classes. Currently the Gobo compiler tries to optimize the C code generation by performing a system level analysis of the Eiffel code. Which means that, unless you just change one character in one string, it is likely that every C file would change after each compile. In order to be truly incremental at the C level, the Gobo compiler should have another C code generation mode which is more focused on preserving the C code unmodified rather than on global optimization. This is the same thing as in ISE's EiffelStudio with workbench (frozen) and finalize modes.=20 Currently the Gobo compiler only has the finalize mode. </pre> </blockquote> <font face=3D"DejaVu Sans Mono">Hi Eric, Guillaume,<br> <br> excuse when i drop into your discussion. <br> <br> Conceptually, splitting C code per class or type should not very hard: <br> writing a type's struct or routine had to be enclosed into file-open, file-close parentheses, one file per type. <br> <br> I see the problem at another level. Consider a large Eiffel system, e.g. the GEC. <br> It consists of about 2000 alive types (i.e. types where C code is to be generated) from about 670 classes. Compilation may be per type or class but linkage needs all file names in the command line. The Unix command line allows after resolution of wildcards etc. for about 32000 characters (I do not know which restrictions Windows applies, if any). So we have up to 16 characters for 2000 files, three characters</font><font face=3D"DejaVu Sans Mono"><font face=3D"DejaVu Sans Mono"> </font> are reserved: the dot, the extension 'c', the separating blank. This means class or type names are in general too long and artificial file names are to be generated like "gec1234.c". This is the way, EiffelStudio tackles the problem: compilation of the many C files having cryptic names in manageable chunks to intermediary object files and then linkage of the much fewer objects. The problem for GEC would be to generate the same file names for unchanged types/classes across various compilations, since it was the intension to reuse all the unchanged C code. EiffelStudio is an IDE, comparison of system states between forthcoming compilations is duty of the project management, unchanged parts will be detected and can be reused. So, the GEC had first to be upgraded to an IDE. <br> <br> Taking all together, it is worth thinking again about C code generation per type/class without turning GEC into an IDE. The true complication is organizing the make utilities for compilation in chunks. The risk for the user is to C-compile all the stuff if too many generated file names changed, the gain for the user is much less C-compilation time if file names were rather stable. <br> <br> Wolfgang<br> </font> <pre class=3D"moz-signature" cols=3D"72">--=20 Dr. Wolfgang Jansen Lauenburger Stra=DFe 40 D-12169 Berlin Tel: (+49) 0172 40 86 916 e-mail: <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:wo.jansen@ka= belmail.de">[email protected]</a></pre> </body> </html> --------------000903080206080802090907-- --===============8853579179109802242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ --===============8853579179109802242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ gobo-eiffel-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop --===============8853579179109802242==--