On 2006-08-15, Guilhem Bonnefille <[EMAIL PROTECTED]> wrote: > ------=_Part_6491_9682167.1155645004632 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > I'm surprised about the critics made about the job done by the GCC team. > They do the job every body expect them. > > Yes, C and related tools (compiler, linker and so on) are not high level > tools. They need sufficient skill to handle them. So they are > "user-friendly", but for skilled people. In the other hand, they are > powerfull for people that know them.
No, they're not. Having to waste time in a task that could be easily be automated is not powerful. Nobody works sum, multiplication and long division algorithms on pencil and paper anymore, except when learning basic arithmetic. You let the computer do it. Likewise you should not have to work out the order in which to pass the libraries to a compiler, when the compiler can do it with very little effort. User-friendliness is about doing what the user wants to be done, with as little unwanted effort from the user as possible. It has nothing as such to do with skilled and unskilled people, although although these kinds of users may have very different tasks at mind, and definitions of unwanted effort. The WIMP GUI aka. the search-for-hours-and-click UI is by this definition very user-unfriendly, but so is GCC's handling of archive dependencies. It is worth noting that it does, obviously, allow object files (.o) unordered or even cyclic dependencies among them. But an archive is just a collection of object files! > In a same way, ion* is a powerfull window manager, but it is not as > "user-friendly" as other window manager. It requires some investment before > being "user-friendly". The only investment that can make gcc user-friendly is fixing it, or writing a user-friendly higher-level tool (which again do not include autocrap, which are awful for both the developer and user alike). That's quite big an investment, uncomparable to the task of learning a program. > So please, avoid critics around GCC team. Yes, the GNU linker (like other > UNIX linkers) does not handle circular dependencies, but it is not expected > do handle them. It just does a simple job, so it is easy to understand it. I'm not even asking for cyclic dependencies (although they should be no problem to support)! All I'm asking is that if foo.a depends on bar.a, but bar.a doesn't depend on foo.a, then I can pass either 'gcc foo.a bar.a' or 'gcc bar.a foo.a' without having the think about it, or write such complex makefiles (a lot of unwanted work!) that try to take care of that. -- Tuomo
