Darren New <dne### [at] sanrrcom> wrote:
> >   All things considered, I don't think that this simple case is all that
> > complicated. (The only complicated thing is figuring this out.)

> I agree. Not sure why you're making such a big thing of me pointing out that 
> the simple system works fine with shell scripts.

  When talking about a project building system, a shell script is a
significantly more primitive tool than a makefile because shell scripts
are not designed specifically to deal with dependencies and building
projects, while makefiles are. You could say that shells scripts are
(significantly) *more* generic than makefiles. Going to the more primitive
tool is going to the wrong direction. You should go towards the tool that
is more designed for the task at hand.

  Your initial argument pro shell scripts is that, according to you, they
are simpler to create for the original task in this thread than a makefile,
which, again according to you, is the "wrong" tool.

  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 (at least when using gnu make, which is the default for all
linux distros). You thought that you need to write a lot more. Hence you
mistakenly advocated shell scripts as the "simpler" solution, when they
really aren't. (Just compare your shell script solution to the makefile
examples I posted earlier and consider honestly which one is simpler.)

  'make' is not the wrong tool for what he wants to do, unlike what you
claimed. A shell script will not make the whole process any simpler.

  Could there be any better tools than gnu make for this task? Well, if
you don't need to track dependencies (as Andrew clearly didn't have to),
then no: gnu make performs the task perfectly with just a couple of simple
lines. I don't think any other tool could make a better job at it.

  If he wanted to automatically track all source file dependencies (in his
linux environment), then yes, there could be (and are) better tools for
this, tools which are even more specialized than 'make' and can automate
the process with less magic keywords and commands. However, such tools are
not necessarily included in many standard linux distributions, while gnu
make is (at least if you have installed any compiler, and probably even
regardless). 'make' is more "standard" (in a sense) than those other more
specific tools. In this particular case, however, there would be little
benefit in using those.

  It seems to me that you are opposing 'make' just as a matter of principle
rather than as a matter of practicality. You'd rather have him use shell
scripts rather than makefiles, for whatever reason.

> >>>   (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?

  gnu make is a pretty standardized tool in linux distros (and many other
unixes). How do you "abuse" a standard tool when using it for its intended
purpose?

> Nope. It doesn't have to read your mind.  Of course it has to know what to 
> compile.

  Well, that was what I said, and you said that was incorrect.

> 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.

  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.)

> I have no problem telling a C compiler what and where my program is. I just 
> don't think it's a good idea to have to tell a C compiler where everyone 
> *else's* source code for libraries that are already compiled is.

  I don't have to tell it either. I don't even remember where exactly eg.
the C++ standard header files are in my OpenSuse system. Probably somewhere
inside /usr/include/something. The compiler is already configured to find
them so I don't have to care.

  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.

  If I install a third-party library *locally* somewhere in my home directory
(rather than systemwide), *then* I may need to add a couple of compiler
options to tell the compiler where to find it. However, that seems pretty
obvious. After all, I have installed the library in a nonstandard location.
The compiler cannot guess where if I don't tell it.

  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. (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.)

> (As far as me bashing, I find it amusing that when I bash a feature in C 
> that's improved in C++, you don't get upset, but if I bash a feature in C 
> that is carried over to C++, you justify it out the wazoo.)

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

> >>> You are making it sound like most other languages
> >>> don't need to be told where the libraries and source files are.)
> > 
> >> Generally, other languages don't need to be told where the sources for a 
> >> particular library are stored, no.
> > 
> >   Bullshit. Specific compilers might have *default* paths for the libraries,
> > and so does a typical gcc installation in linux. That doesn't mean that
> > the compiler is not being told where the libraries are.

> 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.

  I don't get your point.

> 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.

> >   Nevertheless, why should I care if some #include file information is
> > duplicated, as long as it happens automatically?

> Because now you need a third-party tool to automate dependency generation.

  If you consider the C preprocessor a "third-party tool".

  Even if you do, so what?

-- 
                                                          - Warp

Post a reply to this message