Warp wrote:
>   The problem is that you didn't know that you can actually implement what
> Andrew wanted with just a couple of simple and straightforward lines with
> a makefile 

Of course I knew that. Don't be insulting.

>>>>>   (And granted, with a "standard" non-gnu makefile you would need more
>>>>> than this.)
>>>> Another problem with make (and similar tools that get abused).
>>>   I honestly cannot undrestand why you call this "abuse". 
> 
>> Your reading comprehension is poor. Where did I say what you wrote is an 
>> abuse of make?  Answer: I didn't. I said that having a bunch of different 
>> versions is indicitive of a program whose capabilities have been expanded 
>> over time bit by bit without a coherent plan, in such a way that such 
>> extentions tend to get abused.
> 
>   I think it's you who didn't understand. What exactly is this 'make'
> abuse you are talking about?

If you've never seen abuse of makefiles, then power to you. I think anyone 
who has worked on an ugly system knows what I'm talking about. Otherwise, go 
look up the "buildroot" system for compiling kernels.  I mean, hell, 
buildroot was so makefile-abusive that people capable of working on the 
linux kernel said "screw this, let's throw it away and start over."

>> The problem is not that you have to tell the compiler what to 
>> compile. The problem is you have to (in C) compile much more than your own 
>> source code in order to compile your program.
> 
>   You have odd problems. I haven't encountered such a problem as far as
> I remember.

Well, good for you. The fact that you've not encountered that problem 
doesn't mean that the problem isn't real.

>   Maybe compilation times would get faster if the source files didn't depend
> on gigantic header files? Probably. However, I haven't personally encountered
> this as a problem, as I have never had to deal with gigantic projects with
> millions of lines of code. (I do understand that it might be a nuisance in
> such huge projects, though.)

Well, let me know when you've taken the source code for an entire toolchain, 
kernel, and application stack and cross-compiled it from scratch. Let me 
know how easy it is to figure out where everything goes when your makefiles 
download from FTP sites other makefiles and then run them thru sed to patch 
up the errors in them before invoking them, and then come back and tell me 
it isn't a problem.

>   If I install a new library from a OpenSuse repository, I still don't have
> to care where it's installing it. In fact, I don't even *know* where it's
> installing them, and I don't need to. They will still work.

Here you're arguing that someone else has already solved the problem for you.

>   Can this scheme sometimes cause *more* problems than when dealing with
> C# on Windows using Microsoft's IDE? Probably. It hasn't bothered me too
> much so far, though. 

Great. Install compilers for three different versions of Linux for three 
different architectures on the same machine. Make sure that you can use all 
three different versions of boost you need on each of those three compilers. 
Let me know how simple your makefiles are.

(And you're giving *me* shit about not knowing how makefiles work? Really??)


> (Although I would be surprised that if you installed
> a C# library in a nonstandard location, you wouldn't have to explicitly
> tell the compiler where to find it. Well, unless the library installer
> doesn't tell it automatically, but that's just a technicality.)

I could describe how it works, but you're not interested enough to read it.

>   No, I oppose bashing C (and C++) for flaws that it doesn't really have.

You mean "flaws you haven't encountered".  Good for you.  Maybe I've used C 
more than you have even.

>> You don't understand the word "sources" in that sentence?  Reading 
>> comprehension, dear.
> 
>   I don't think I have the sources eg. for libc.so installed in this
> system, hence I don't have to tell the compiler where they might be.

Um, yes, you do. You have the sources for some of the openssl libraries 
installed, don't you?

>   I don't get your point.

Yes you do.

>> The fact that you can automate (in some cases) the copying of dependencies 
>> from one place to another does not mean you're not copying dependencies from 
>> one place to another.
> 
>   And I asked why should I care if it happens automatically behind the
> scenes.

And I answered this repeatedly, and you picked nits instead about whether 
invoking the C preprocessor is invoking the compiler or not.

>> Because now you need a third-party tool to automate dependency generation.
>   Even if you do, so what?

I already answered that.

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message