But like pencil and paper, it is possible to do some things impossible if the tools are too much "user-friendly". I'm not sure about the interest, but...
You are right again when you said that a tool can probably save lots of time if it handle compilation to make it easy. So, why not produce it? ;-)
Seriously, the job you expect (automatic dependency solving at compilation time) could probably made by a tool. But actually, I don't know it.
So, actually, by choosing C as language, we have to anticipate problems to make life easier. Tons of library are a problem because it requires manual job (to solve dependency).
Instead of .a (that are only archive of .o), have you looked around .so? These objects store dependencies. If foo.so depends on bar.so, it stores the dependency (if you made the right compilation command line). Next, when loading foo.so, it will request for loading bar.so.
I don't remember if this solves the compilation problem. For exemple, when linking whith foo.so, does it automatically check bar.so or simply marks symbols unresolved.
Perhaps, one solution when you don't want to waste time in solving compilation/linking problems, before changing language, is to use IDE. I know that Eclipse/CDT offer a way to automatically manage compilation/linking. Another could be Anjuta, but I don't know it. There are probably other IDE for C.
On 8/15/06, Tuomo Valkonen <[EMAIL PROTECTED]> wrote:
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
--
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED]
-=- mailto:[EMAIL PROTECTED]
-=- http://nathguil.free.fr/
