* Separate dir for the C frontend
@ 2004-09-12 1:32 Gioele Barabucci
2004-09-12 1:32 ` Joseph S. Myers
0 siblings, 1 reply; 2+ messages in thread
From: Gioele Barabucci @ 2004-09-12 1:32 UTC (permalink / raw)
To: gcc
Now that the SC has decided to switch from 3.5 to 4.0, I think the time
has come to put the C frontend in its own directory and leave toplevel
gcc/ for shared routines. I know this move is not simple, but it has to
be done sooner or later, and this major number change is the last
occasion before 5.0 (that will probably come in three or more years).
And please don't postpone this move because of mainline being on stage 3:
the change on version numbering has been announced after the mainline
freeze...
--
Gioele Barabucci <barabucc@cs.unibo.it>
) http://cs.unibo.it/~barabucc
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Separate dir for the C frontend
2004-09-12 1:32 Separate dir for the C frontend Gioele Barabucci
@ 2004-09-12 1:32 ` Joseph S. Myers
0 siblings, 0 replies; 2+ messages in thread
From: Joseph S. Myers @ 2004-09-12 1:32 UTC (permalink / raw)
To: Gioele Barabucci; +Cc: gcc
On Sun, 12 Sep 2004, Gioele Barabucci wrote:
> Now that the SC has decided to switch from 3.5 to 4.0, I think the time
> has come to put the C frontend in its own directory and leave toplevel
> gcc/ for shared routines. I know this move is not simple, but it has to
> be done sooner or later, and this major number change is the last
> occasion before 5.0 (that will probably come in three or more years).
Such a change has zero user visibility. Accordingly, version number
changes are completely irrelevant to it.
> And please don't postpone this move because of mainline being on stage 3:
> the change on version numbering has been announced after the mainline
> freeze...
This change was not proposed before the move to Stage 3, has zero user
visibility or benefit, and does not fix any bugs; it would be solely for
developer convenience; furthermore, it has nonzero risk of causing build
system bugs. Accordingly, it is not justified in Stage 3.
While I do have an idea for the proper directory structure, the change is
not appropriate until Stage 1.
(My idea is c-family/ for files shared by all C family languages, with
c-common.c split into more meaningfully named files, c/ for files used by
C and in most cases by ObjC. This structure is intended not to prejudice
any possible future merge of any of the front ends; with merged front ends
code in one directory could more freely call functions in other
directories, conditional on the language or on datastructures only some
languages create, and the amount of code in the different directories
might vary, but the concept of code specific to a particular subset of
languages, with conditionals to choose between variations, would still
apply in such a case.)
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 4.0
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-09-12 0:14 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-12 1:32 Separate dir for the C frontend Gioele Barabucci
2004-09-12 1:32 ` Joseph S. Myers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).