Subject: Bug#3838: GCC should depend on CPP, not conflict with it

From: [email-masked] (David Engel)
Date: Thu, 1 Aug 1996 09:50:36 -0500 (CDT)

Ian Jackson writes:
> David Engel writes ("Re: Bug#3838: GCC should depend on CPP, not conflict with it"):
> > This would force an exact version match between cpp and gcc and I
> > would very much like to avoid those situations.  Yes, I know this is
> > already done with shared library run-time and development packages.
> > Unless you can come up with a better suggestion, I can have cpp and
> > gcc conflict AND replace each other.
> 
> Hmm.  Why is it necessary for gcc to know which version of cpp is
> available, or for it to have exactly the right one ?

Would you want the front-end driver (gcc) to use different versions of
cpp and cc1/cc1plus?

David
-- 
David Engel                        Optical Data Systems, Inc.
[email-masked]                      1101 E. Arapaho Road
(214) 234-6400                     Richardson, TX  75081

---

From: Ian Jackson <[email-masked]>
Date: Thu, 8 Aug 96 15:27 BST

> Ian Jackson writes:
...
> Would you want the front-end driver (gcc) to use different versions of

Forgive my naivete', but I don't see why it should matter.

Ian.

---

From: [email-masked] (David Engel)
Date: Fri, 9 Aug 1996 14:14:21 -0500 (CDT)

> Forgive my naivete', but I don't see why it should matter.

Because they're designed to work together.  That's why the FSF
includes cpp with gcc instead of packaging it separately.  

David

---

From: Ian Jackson <[email-masked]>
Date: Sat, 10 Aug 96 00:21 BST

> includes cpp with gcc instead of packaging it separately.  

This doesn't much sense to me, at least not without more detail.

Why do gcc and cpp need to know each other's particular versions ?

There are lots of other things that are designed to work together
where a bit of version slippage doesn't matter.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Wed, 21 Aug 96 23:36 BST

David Engel writes ("Re: Bug#3838: GCC should depend on CPP, not conflict with it"):
> cpp, cc1, cc1plus, etc., together comprise what we loosely call gcc.
> They work together as a closely matched set, and consequently, need to
> stay exactly in sync in much the same way that dpkg and dselect need
> to stay exactly in sync.

I'm sorry to say that I still don't understand.  You haven't, as far
as I can see, actually explained what complicated dependencies cpp and
cc1 and the compiler driver gcc have on each other - you've just
restated the claim that they have such complicated dependencies.

For example, if I were asked whether one version of dpkg could work
with a different version of dselect I'd say: mostly yes, but sometimes
I change the format of some files in /var/lib/dpkg or occasionally I
introduce a new option to dpkg for dselect to use and then you would
need to upgrade together.

Can you give me an answer like that for cpp/gcc/cc1/cc1plus &c ?

As far as I can tell the hardest thing would be getting the right
version numbers into the predefined macros __GCC__ or whatever they
are, and this doesn't seem hard to solve.

After all, the input and output formats of cpp are defined by the fact
that it has to be a C preprocessor accepting and producing valid C.
There seems not much scope in the output from cpp for making it tied
to a particular cc1 version.

In any case, even if this is true it would probably be better to have
the two packages depend on exact versions of each other.

> This isn't one of those cases.
> 
> I making gcc and cpp conflict with and replace each other in version
> 2.7.2.1.  This should make it easier for users to switch between them.
> Until I hear a better suggestion that doesn't involve duplicating
> files, or keeping two packages exactly in sync, I'm going to leave it
> this way.

Please do _not_ make either of these packages Replace the other.

This is not what Replaces is for, and in the future dselect will take
enough notice of Replaces that this will cause confusion in it and
probably in the user.

I'm going to reopen this bug for at least this last reason.

Ian.