--- "Peter A. Friend" <octavian@xxxxxxxxxxxxxxxxxx> wrote: > > On Dec 4, 2007, at 11:00 AM, Thomas Dineen wrote: > > > Issue 4) What's In A Name? Or what the hell > should we name it? > > When I down load and install various releases of > GNU Bintools a > > tool like GNU Make is sometimes called gmake and > sometimes called > > make. This causes confusion and thus errors in > that the Gcc build > > scripts > > use make. I would suggest standardizing on the > names to prevent > > confusion. > > To this end I would suggest that GNU Make always, > always, always be > > called gmake and when you want to use GNU Make in > your project that > > you type gmake. > > I don't see how this is a GNU bug, it's more of a > development > environment issue. When we install GNU make we > install it as "make" > and also provide a hard link as "gmake". If it was > only installed as > gmake then people would have to alter all of their > stuff (something > they may not have access to do) to call gmake. > > For my Solaris environment I have the GNU tools in > my path first, > followed by /usr/ccs/bin. This makes sure that GNU > versions of m4, > grep, sed and make are used, and Sun versions of as > and ld are used. > If I have a naming issue, as in makefiles compiling fortran code that assume the fortran compiler is g77 (yes I know that is a bug, but I am dealing here with open source packages distributed by others), and once I have compiled gcc, the compiler that should be used is gfortran, I just create an alias that results in gfortran being invoked whenever the the g77 compiler is invoked, effectively hiding the ancient compiler that ships with cygwin and ensuring the new one is used instead. This is something I learned the hard way, studying bash. But, it seems to work fine when trying to compile any of the various open source packages using gcc 4.2.1 within cygwin. > > > Issue 5) The build process is way to complicated > for the average user > > to negotiate successfully. The user interface > should be simplified > > to the > > following for a native compiler: > > ./configure > > gmake > > gmake install > > The build procedure for GCC can be cumbersome. There > are a lot of > options, a lot of systems to support, and a lot of > ways for the > procedure to break. This in itself is an argument > against average > users trying to attempt builds themselves. > I don't know about that. The configure, make, make check, make install sequence seems to work fine for me, and I am not a compiler developer. Granted, a little trial and error allows me to add specific options to improve things, but configuring and then building, testing and installing GCC is not what I would call hard, even for the average user who can read. And there is little option in some cases, since, for example, on cygwin, the last time I checked, the most recent GCC available for download was version 3.4. If I were content to just accept what cygwin chooses to provide, I would always be stuck with older tools. Yet, building gcc allows me to work with the latest release, so I can benefit from all the improvements that become available as they become available. I wouldn't want an average user to be scared off of trying to build GCC just because a few have some trouble. I don't work with beta products, but in my experience with releases of GCC, trying to compile them on Windows using cygwin, I found the documentation available to be fine and the process to be relatively easy compared to other applications I build. Cheers, Ted
