public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: rich-paul@rich-paul.net
To: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
Cc: rich-paul@rich-paul.net, jbuck@Synopsys.COM, egcs@egcs.cygnus.com
Subject: Re: Building binutils, egcs, gdb, etc
Date: Fri, 02 Apr 1999 07:36:00 -0000	[thread overview]
Message-ID: <Pine.LNX.3.96.990402072813.25997A-100000@nitrogen.colossus.net> (raw)
In-Reply-To: <199904020637.IAA00556@mira.isdn.cs.tu-berlin.de>

You're right, on both counts.  But neither of these seems inconsistant
with the requirements of current open-source projects ( my god, look at
gnome ... I had to install gobs of packages ), and it seems to
be worth pursuing from my point of view, as the Mozilla people would say,
"For the good of the code".  One problem with the current approach besides
package size and build time is that there is always for the potential for
mismatches between binutils and gcc, and a programmer working on both
projects would need to know that implementations of 'the same' function
may vary between projects.  Not to mention that projects written with 
binutils need to be read with gdb and visa-versa.

May I ask why these libraries are in constant flux?  It *seems* like their
purpose is pretty cut and dried, but it could be that I do not understand
the problem they solve well enough to know.

Regards,
Rich

P.S.  I would be willing to maintain either or both of these libraries,
if there is interest in changing to this method of distribution.  I've been
looking to find a nitch in a good opensource project, and the project seems
like a worthy one to me.  I'm a c++ guy, but I can do k&r, it's just like
watching a movie in black and white.  <G>

---
There is a party that  |  Libertarian Party  |  A victimless crime is
supports the right to  |  http://www.lp.org  |     a contradiction in 
free speach and        |    The Party of     |                 terms.
encryption!!           |      Principal      |  

On Fri, 2 Apr 1999, Martin v. Loewis wrote:

> > It seems to me like the best way to approach this situation would be to
> > factor out the common parts into a seperate distribution.  This would have
> > the following results ( in theory ).
> [...]
> > Downsides:
> 
> You forgot an important one
> 
>     4) Somebody would have to maintain it, over a period of many
>        years, and be quite responsive to requests of the maintainers
>        of the various packages, as well as to problems end-users have
>        with it. Otherwise, maintainers will just grab a copy of the
>        base package, integrate it, and modify it to their needs.
> 
> I don't see anybody stepping forward to do that. Of course, there is
> also
> 
>     5) Packages are more difficult to install for typical
>        end-users. End-users don't build the entire chain at one time,
>        but they build gdb whenever a new version is release, and
>        binutils whenver that is updated. They now download the source
>        and compile. Under your scheme, they also have find out what
>        else they need (i.e. the base package), and where they can get
>        it.
> 
> Regards,
> Martin
> 

WARNING: multiple messages have this Message-ID
From: rich-paul@rich-paul.net
To: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
Cc: rich-paul@rich-paul.net, jbuck@Synopsys.COM, egcs@egcs.cygnus.com
Subject: Re: Building binutils, egcs, gdb, etc
Date: Fri, 30 Apr 1999 23:15:00 -0000	[thread overview]
Message-ID: <Pine.LNX.3.96.990402072813.25997A-100000@nitrogen.colossus.net> (raw)
Message-ID: <19990430231500.ARUeYuuaTV9QFHHmioV7fxdKANDGTnOhgdXRBZ-HiAU@z> (raw)
In-Reply-To: <199904020637.IAA00556@mira.isdn.cs.tu-berlin.de>

You're right, on both counts.  But neither of these seems inconsistant
with the requirements of current open-source projects ( my god, look at
gnome ... I had to install gobs of packages ), and it seems to
be worth pursuing from my point of view, as the Mozilla people would say,
"For the good of the code".  One problem with the current approach besides
package size and build time is that there is always for the potential for
mismatches between binutils and gcc, and a programmer working on both
projects would need to know that implementations of 'the same' function
may vary between projects.  Not to mention that projects written with 
binutils need to be read with gdb and visa-versa.

May I ask why these libraries are in constant flux?  It *seems* like their
purpose is pretty cut and dried, but it could be that I do not understand
the problem they solve well enough to know.

Regards,
Rich

P.S.  I would be willing to maintain either or both of these libraries,
if there is interest in changing to this method of distribution.  I've been
looking to find a nitch in a good opensource project, and the project seems
like a worthy one to me.  I'm a c++ guy, but I can do k&r, it's just like
watching a movie in black and white.  <G>

---
There is a party that  |  Libertarian Party  |  A victimless crime is
supports the right to  |  http://www.lp.org  |     a contradiction in 
free speach and        |    The Party of     |                 terms.
encryption!!           |      Principal      |  

On Fri, 2 Apr 1999, Martin v. Loewis wrote:

> > It seems to me like the best way to approach this situation would be to
> > factor out the common parts into a seperate distribution.  This would have
> > the following results ( in theory ).
> [...]
> > Downsides:
> 
> You forgot an important one
> 
>     4) Somebody would have to maintain it, over a period of many
>        years, and be quite responsive to requests of the maintainers
>        of the various packages, as well as to problems end-users have
>        with it. Otherwise, maintainers will just grab a copy of the
>        base package, integrate it, and modify it to their needs.
> 
> I don't see anybody stepping forward to do that. Of course, there is
> also
> 
>     5) Packages are more difficult to install for typical
>        end-users. End-users don't build the entire chain at one time,
>        but they build gdb whenever a new version is release, and
>        binutils whenver that is updated. They now download the source
>        and compile. Under your scheme, they also have find out what
>        else they need (i.e. the base package), and where they can get
>        it.
> 
> Regards,
> Martin
> 


  reply	other threads:[~1999-04-02  7:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-04-01 13:02 rich-paul
1999-04-01 13:49 ` Martin v. Loewis
1999-04-01 14:04   ` rich-paul
1999-04-01 14:31     ` Joe Buck
1999-04-01 14:55       ` rich-paul
1999-04-01 19:08         ` Jeffrey A Law
1999-04-30 23:15           ` Jeffrey A Law
1999-04-01 21:51         ` David Edelsohn
1999-04-30 23:15           ` David Edelsohn
1999-04-01 22:44         ` Martin v. Loewis
1999-04-02  7:36           ` rich-paul [this message]
1999-04-04 10:20             ` rich-paul
1999-04-30 23:15               ` rich-paul
1999-04-30 23:15             ` rich-paul
1999-04-30 23:15           ` Martin v. Loewis
1999-04-30 23:15         ` rich-paul
1999-04-30 23:15       ` Joe Buck
1999-04-01 14:44     ` Martin v. Loewis
1999-04-01 14:56       ` rich-paul
1999-04-30 23:15         ` rich-paul
1999-04-01 18:42       ` Doug Semler
1999-04-01 19:10         ` Jeffrey A Law
1999-04-30 23:15           ` Jeffrey A Law
1999-04-30 23:15         ` Doug Semler
1999-04-30 23:15       ` Martin v. Loewis
1999-04-30 23:15     ` rich-paul
1999-04-30 23:15   ` Martin v. Loewis
1999-04-30 23:15 ` rich-paul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.3.96.990402072813.25997A-100000@nitrogen.colossus.net \
    --to=rich-paul@rich-paul.net \
    --cc=egcs@egcs.cygnus.com \
    --cc=jbuck@Synopsys.COM \
    --cc=martin@mira.isdn.cs.tu-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).