Linux-Development-Sys Digest #925, Volume #6 Fri, 2 Jul 99 17:14:20 EDT
Contents:
Re: Install Mandrake 6.0 on laptop (compaq armada 6500) (Matt Foster)
Re: Why not C++ (Christopher B. Browne)
Re: help:why program can be run inside gdb but can not in command line (Daniel R.
Grayson)
Re: Why not C++ (Johan Kullstam)
Re: Postgresql Success rate (Doug DeJulio)
Re: RAID-1 and 2.2.9 revisited ([EMAIL PROTECTED])
macros in linux src code (was Re: Why not C++) (John E. Davis)
Domain Names Limited to two or three Characters? ("JDJohnson")
Re: C++ templates: More than Turing Complete? (Davin McCall)
Re: Why not C++ (Timo Tossavainen)
Re: Smallest memory allocation block? (Eric Buddington)
Module Debugging??? ("Malcolm MacNiven")
Re: C++ templates: More than Turing Complete? ("Tom Leete")
Re: Why not C++ (Greg Comeau)
Re: C++ templates: More than Turing Complete? (Johan Kullstam)
Re: Why not C++ (Doug DeJulio)
Re: C++ templates: More than Turing Complete? (Alexander Viro)
Re: C++ templates: More than Turing Complete? (Greg Comeau)
Re: Why not C++ (Greg Comeau)
Re: GNU make help (Paul D. Smith)
Re: Why not C++ (Nathan Myers)
----------------------------------------------------------------------------
From: Matt Foster <[EMAIL PROTECTED]>
Subject: Re: Install Mandrake 6.0 on laptop (compaq armada 6500)
Date: 2 Jul 1999 10:48:47 GMT
Diggy <[EMAIL PROTECTED]> wrote:
: Now, I install Mandrake 6.0 on Laptop (Compaq Armada 6500). But I can't
: set XWindows because I can't set video driver. If you know, how to set
: video driver and monitor please help me.
I have Slackware 3.6 running on the same system.
Take a look at http://www.molnir.demon.co.uk/ for
my ramblings on how it was done.
Matt
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Reply-To: [EMAIL PROTECTED]
Date: Fri, 02 Jul 1999 13:03:02 GMT
On Fri, 02 Jul 1999 21:08:03 +1200, Bruce Hoult
<[EMAIL PROTECTED]> posted:
>In article <7lhcpa$[EMAIL PROTECTED]>, o r c @ p e l l . p o r
>t l a n d . o r . u s (david parsons) wrote:
>> Dylan is Yet Another Pascal, isn't it? It looks like the bastard
>> child of a shotgun marriage between Ada and Pascal.
>
>Perhaps you're thinking of Modula-2 or Oberon?
Wouldn't it be more like Pascal and Common Lisp?
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
From: [EMAIL PROTECTED] (Daniel R. Grayson)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: help:why program can be run inside gdb but can not in command line
Date: 02 Jul 1999 08:59:23 -0500
y chen <[EMAIL PROTECTED]> writes:
> Hello , there ,
> I had a program and i can run it inside gdb
> without any problem.
> However, When i run it in command line,
> it seg fault.
> Does anyone have same experience and
> tell me how to fix it?
> Thanks!
This can happen if gdb doesn't present exactly the same environment to the
program. For example, I just tried running /usr/bin/printenv with and
without gdb, and it gives different answers for the environment variables "_"
and "PS1". See the printout below. It's easy to imagine a bug whose
behavior depends on the value of environment variables, because the total
size of the environment strings, which are stored on the stack, affects the
location of the top of the stack when main() is called, and thus it affects
the values of all pointers to variables on the stack.
This could be considered a bug in gdb, since it makes it impossible to debug
certain programs.
I would experiment with random environment values to see whether you can get
the segmentation fault in gdb, e.g.,
export FOO=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
gdb
=============================================================================
% /usr/bin/printenv _
/usr/bin/printenv
% gdb /usr/bin/printenv
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-pc-linux-gnu"...
(no debugging symbols found)...
(gdb) run _
Starting program: /usr/bin/printenv _
bash
Program exited normally.
(gdb)
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: 02 Jul 1999 08:17:34 -0400
[EMAIL PROTECTED] (Nathan Myers) writes:
> Johan Kullstam <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] (Greg Comeau) writes:
> >> [EMAIL PROTECTED] writes:
> >> >In my opinion C++ is not the most powerful, but the first hyped OOPL.
> >
> >> This does not
> >> consider the OOPL's at the time there _were_ hyped. C++ had _every_
> >> opportunity to fail, exactly because it was NOT hyped. It was
> >> strictly though it's own merits that it is where is it today.
> >
> >C++ allowed an easy transition from the language flavor of the decade
> >which in the years from 1985 to 1995 (roughly) was C. it's not that
> >C++ was spectacularly better than all other object oriented languages.
> >it just incrementally solved enough that people kept going with it.
> >
> >worse is better.
>
> Grapes *sure* are sour, aren't they?
>
> Only people who take the trouble to understand why C++ solves real
> problems better than the alternatives have any hope of designing a
> language that can supplant it. (Hint 1: copying the syntax might
> be a mistake.)
the only way to supplant C++ is to have an easy migration path from
it. look at dos and windows. you might say they're like C and C++.
it's hard to supplant microsoft because people are always asking if
they can run ms word or excel. it's the same way C people ask if the
new language has static types and is backward compatible to C.
linux is a unix clone and while i like linux and unix in general, the
operating system itself is no great innovation. i mean linux is a
good implementation of unix and the open development model is nice.
however open development was the way unix was done back in the
seventies so that isn't really all that new either.
--
johan kullstam
------------------------------
From: [EMAIL PROTECTED] (Doug DeJulio)
Crossposted-To: ahn.tech.linux,alt.os.linux,comp.os.linux.development.apps
Subject: Re: Postgresql Success rate
Date: 2 Jul 1999 10:18:11 -0400
In article <7ldkt9$26kc$[EMAIL PROTECTED]>,
Alexander F. Hartner <[EMAIL PROTECTED]> wrote:
>Has anybody experienced serious problems using Postgresql 6.4 with Java
>(JDBC) on a medium size network. Is Datacorruption a problem. From what I
>have experienced in the short time that I have been using Postgresql it is
>the best thing since sliced bread, but people seem unsure to use it.
I've been running PostgreSQL for a very long time (since it was
"Postgres95 1.02" I believe), and have never been bitten by it. Other
people have experienced all sorts of problems. How stable and safe it
is seems historically to have depended on how you happened to use it.
Today, we make extensive use of a lot of advanced features in
PostgreSQL. We've been stressing it harder and harder as time goes
on. Fortunately, any bugs we would have encountered as we used more
features seem to have gotten fixed before we needed those features.
plan to continue using it.
--
Doug DeJulio | mailto:[EMAIL PROTECTED]
HKS, Incorporated | http://www.hks.net/~ddj/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RAID-1 and 2.2.9 revisited
Date: 2 Jul 1999 15:18:18 GMT
patman <[EMAIL PROTECTED]> wrote:
: I think I have a fix for the resync problem:
: Following the lead from ([EMAIL PROTECTED]) in the linux-raid
: mailing list, I edited /usr/src/linux/drivers/block/md.c, and changed
: the TWO occurrances of "current->priority = 0" to "current->priority =
: 1", and resync started working just fine. As a nice side effect, I can
: reboot the system cleanly now (was hanging up waiting for the resync
: process to die off)
Cool. This ought to hold us until Ingo releases the next set of patches.
Cheers,
RF B
------------------------------
From: [EMAIL PROTECTED] (John E. Davis)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: macros in linux src code (was Re: Why not C++)
Date: 2 Jul 1999 16:53:25 GMT
Reply-To: [EMAIL PROTECTED]
[Subject changed]
On 02 Jul 1999 09:21:58 +0200, Klaus-Georg Adams <[EMAIL PROTECTED]>
wrote:
>from /usr/src/linux-2.2.9/include/asm-386/system.h, line 193:
>
>#define save_flags(x) ((x)=__global_save_flags())
This is not good. Perhaps Linus should add something about macros to
the CodingStyle document that is distributed with the source.
--John
------------------------------
From: "JDJohnson" <[EMAIL PROTECTED]>
Subject: Domain Names Limited to two or three Characters?
Date: Fri, 2 Jul 1999 12:00:26 -0400
Are domain names limited to two (.uk, .de) or three (.com, .org, .edu, .gov)
characters in length? If not is there a max number of characters?
Thanks
J
------------------------------
From: [EMAIL PROTECTED] (Davin McCall)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: Fri, 02 Jul 1999 17:03:49 GMT
Oh dear. Yes, I imagine most compilers would choke on that one... but
I'm sure I could write a functionally equivalent (in terms of
input/output) program in a finite amount of assembly in a finite
amount of time.
In fact, given any script which terminates (in any scripting language)
it should be at least *possible* to produce an equivalent assembly
program (or equivalent C program or whatever) of finite length and
complexity, should it not?
I should have qualified "compile" with "successfully" I suppose...
Davin.
On 02 Jul 1999 09:18:04 +0200, Stephan Houben
<[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Davin McCall) writes:
>
>> On 1 Jul 1999 01:57:18 -0700, [EMAIL PROTECTED] (Nathan Myers)
>> wrote:
>>
>> >The convention in some communities is to ignore performance
>> >and engineering rigor. Certainly anything can be achieved in
>> >assembly language (or in T-code, if you like) that can be achieved
>> >with a C++ _program_, given infinite time and coding effort.
>>
>> Infinite? Finite, surely!
>>
>> To say that something takes an infinite amount of time to do is to say
>> that it can't be done. And yet, you will find that an assembly
>> language (or machine code) program of finite size and complexity is
>> generated whenever you compile a high level language program, even a
>> C++ program.
>
>No, not every C++ program is compiled to a finite amount of assembly.
>Take the following counter-example:
>----------------begin code------------------
>template <class A>
>void call_me(A a, int i)
>{
> if (i > 0)
> call_me(&a, i - 1);
>}
>
>int main(void)
>{
> int a;
>
> call_me(a, 10);
> return 0;
>}
>-----------------end code------------------
>
>This produces the following error message (with gcc):
>test.cc:5: virtual memory exhausted
>
>I guess that an infinite amount of processing time and
>memory space would be sufficient to compile this program
>
>Note that the program, once compiled, would actually terminate
>after 10 recursive calls of call_me().
>
>Also note that a *compiler* that can handle all possible variations
>on this theme would need to be more than Turing complete.
>
>Greetings,
>
>Stephan
__________________________________________________________
*** davmac - sharkin'!! [EMAIL PROTECTED] ***
my programming page: http://yoyo.cc.monash.edu.au/~davmac/
------------------------------
From: Timo Tossavainen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: Fri, 02 Jul 1999 20:27:45 +0300
Nathan Myers wrote:
>
> Only people who take the trouble to understand why C++ solves real
> problems better than the alternatives have any hope of designing a
> language that can supplant it.
There you go again. I don't understand why C++ solves real
problems better than the alternatives, even though I've
been programming C++ for several years.
Take for example the GoF "Design Patterns"-book, which clearly
shows how C++ has to be forced around several real world
problems that occur in _dynamic_ software. For instance, the
Command pattern, Lisp has a solution for the problem that is
faster to code than you can say "lexical closure". The
Serializer Pattern coupled with Factories can be in most cases
accomplished with the regular Lisp print- and read-functions.
In dynamic languages you can basically forget half of the
Pattern book.
There are numerous successful projects written in Lisp. Lisp
is one of the oldest programming languages and it's still
among the best. What does that tell you about dynamic
languages ? They evolve to fullfill the changing needs of the
users; static languages eventually fade away and die.
If your definition of better is faster and smaller, without
regard for development speed, extensibility, maintainability
and robustness, then I understand your point.
> (Hint 1: copying the syntax might be a mistake.)
Yes, the prefix-notation of Lisp is a lot more powerful than
the infix-notation of C++.
Timo
"In the meantime C++ has admirably played its role: that of a
transition technology" -- Bertrand Meyer, OOSC2
OTOH, he didn't say anything bad about Common Lisp.
------------------------------
From: [EMAIL PROTECTED] (Eric Buddington)
Subject: Re: Smallest memory allocation block?
Reply-To: [EMAIL PROTECTED]
Date: 2 Jul 1999 13:25:42 -0500
In article <7l0odp$ell$[EMAIL PROTECTED]>, Anand wrote:
>What is the smallest amount of memory that Linux allocates? If I do
>"malloc(1)" does Linux allocate only 1 byte from its internal free
>memory pool or is there a minimum amount of memory that is allocated?
>
>If the amount of memory requested is less than this minimum then is the
>remaining memory in the allocated block a waste or is it used for any
>purpose?
This is from memory, so caveat lector...
malloc() only allocates certain block sizes, ranging from a few bytes
to about one page (4k on i86). When you call malloc(), the requested
size is rounded up to the next bigger blocksize. If malloc() already
has a page containing that size element, it allocates from
there. Otherwise, it starts a new page for that blocksize.
Big requests are handled specially.
Eric
------------------------------
From: "Malcolm MacNiven" <[EMAIL PROTECTED]>
Subject: Module Debugging???
Date: Fri, 2 Jul 1999 10:26:44 -0700
Hi,
Can anyone tell me how to use gdb to debug my module? If possible, I'd like
to be
able to debug locally (w/o using a serial connection to another system).
Any info
would be greatly appreciated!
Malcolm
------------------------------
From: "Tom Leete" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: Fri, 2 Jul 1999 11:37:46 -0400
Stephan Houben wrote in message ...
>[EMAIL PROTECTED] (Davin McCall) writes:
>
>>
>> Infinite? Finite, surely!
>>
>> To say that something takes an infinite amount of time to do is to
say
>> that it can't be done. And yet, you will find that an assembly
>> language (or machine code) program of finite size and complexity is
>> generated whenever you compile a high level language program, even a
>> C++ program.
>
>No, not every C++ program is compiled to a finite amount of assembly.
>Take the following counter-example:
>----------------begin code------------------
>template <class A>
>void call_me(A a, int i)
>{
> if (i > 0)
> call_me(&a, i - 1);
call_me(a,i-1); // works better
>}
>
>int main(void)
>{
> int a;
>
> call_me(a, 10);
> return 0;
>}
>-----------------end code------------------
>
>This produces the following error message (with gcc):
>test.cc:5: virtual memory exhausted
You put the compiler in a recursion with no exit. &a is an A*. Each
attempt to compile call_me(A) generates a new function call_me(A*). ..
call_me(A**)... call_me(A***)...
>
>I guess that an infinite amount of processing time and
>memory space would be sufficient to compile this program
>Also note that a *compiler* that can handle all possible variations
>on this theme would need to be more than Turing complete.
Big, too ;-)
>Stephan
This proves you *can* do things with templates you can't do with typedef
Cheers,
Tom
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.lang.c++
Subject: Re: Why not C++
Date: 2 Jul 1999 15:29:25 -0400
Reply-To: [EMAIL PROTECTED]
In article <7lgfb4$rgg$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Chance
Harris) writes:
>Johan Kullstam ([EMAIL PROTECTED]) wrote:
>
>: the developers of C++ think so too. templates are a way to avoid
>: explicit typing.
>
>I disagree.
>
>I think they are a hack to get around the lack of parameterized typing.
Also, do loops are a hack to get around the lack of do loops. Sigh.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: 02 Jul 1999 14:46:50 -0400
Mads Dydensborg <[EMAIL PROTECTED]> writes:
> Stephan Houben <[EMAIL PROTECTED]> writes:
>
> > No, not every C++ program is compiled to a finite amount of assembly.
> > Take the following counter-example:
> > ----------------begin code------------------
> > template <class A>
> > void call_me(A a, int i)
> > {
> > if (i > 0)
> > call_me(&a, i - 1);
>
> Isn't the & an error? I mean, it is legal, and should not matter, but
> it makes no sense.
it *is* legal. the point is that it is
a) a syntactically correct C++ program
b) doesn't have a finite compile time nor finite sized assembly output
the whole point is to be a counterexample to a previous assertion that
a) and b) were mutually exclusive. it's not intended to be useful as
an actual program.
--
johan kullstam
------------------------------
From: [EMAIL PROTECTED] (Doug DeJulio)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: 2 Jul 1999 15:12:03 -0400
In article <[EMAIL PROTECTED]>,
Timo Tossavainen <[EMAIL PROTECTED]> wrote:
>Yes, the prefix-notation of Lisp is a lot more powerful than
>the infix-notation of C++.
Ditto for the postfix-notation of PostScript.
The infix-notation of APL isn't bad though -- all diadic operators
have exactly the same precedence, and in the absence of parenthesis
*everything* is evaluated in right-to-left order (and monadic
operators always operate on the item to their right). It's
nonintuitive at first, but it's never ambiguous (even though new
operators can be defined at will).
Infix notation with mixed precedence is gross, *especailly* when you
can define new operators.
--
Doug DeJulio | mailto:[EMAIL PROTECTED]
HKS, Incorporated | http://www.hks.net/~ddj/
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: 2 Jul 1999 16:16:52 -0400
Oops. Hate to followup to myself, but...
In article <7li0fd$[EMAIL PROTECTED]>, I wrote:
>In article <[EMAIL PROTECTED]>,
>Stephan Houben <[EMAIL PROTECTED]> wrote:
>>No, not every C++ program is compiled to a finite amount of assembly.
>>Take the following counter-example:
>>----------------begin code------------------
>>template <class A>
>>void call_me(A a, int i)
>>{
>> if (i > 0)
>> call_me(&a, i - 1);
^-- arrgh. Sorry, I missed it. That's what one gets for posting
when too low on caffeine...
But comment still stands:
>Nope. You are wrong here. The right question being: what set of types it
>might be applied to? And that problem is *not* TC. Especially with the poor
>polymorphism provided by templates. In that case:
>
>TYPES( main ) = \{map(int,void)\}
>TYPES( call_me ) \subset map(pair(_,int),void)
>map(pair(int,int),void) \in TYPES( call_me )
>map(pair(x,int),void) \in TYPES(call_me) =>
> map(pair(x,int),void) \in TYPES(call_me)
^^^^^^^^^^^^^^^^^^^^^
map(pair(pointer(x),int),void)
>Minimal solution:
>TYPES(main) = \{map(int,void)\},
>TYPES(call_me) = \{map(pair(int,int),void)\}
TYPES(call_me) = \{map(pair(pointer^k(int),int),void): k>=0\}
>In this case functions are not polymorphic at all. Even if they were you
>wouldn't have to compile an infinite amount of variants.
>
>Notice that you don't need to know the full set of potential types -
>natural polymorphism of operations restricts the depth. Now, one *can*
... which is the case here. Set of types has trivial enumeration (they
are trees) and all operations are computable.
The shit might hit the fan if the syntax would allows recursive
functional types (e.g. with recursive typedef - typedef int A(A); would
give a bad PITA)
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: 2 Jul 1999 16:26:31 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> Mads Dydensborg <[EMAIL PROTECTED]>
writes:
>Stephan Houben <[EMAIL PROTECTED]> writes:
>
>> No, not every C++ program is compiled to a finite amount of assembly.
>> Take the following counter-example:
>> ----------------begin code------------------
>> template <class A>
>> void call_me(A a, int i)
>> {
>> if (i > 0)
>> call_me(&a, i - 1);
>
>Isn't the & an error? I mean, it is legal, and should not matter, but
>it makes no sense.
>
>Perhaps this is what you are trying to say?
Yes, because it goes from int to int * to int ** to int ***.....
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 2 Jul 1999 16:14:58 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> Justin Vallon <[EMAIL PROTECTED]>
writes:
>[EMAIL PROTECTED] (Bruce Hoult) writes:
>
>> In article <7lbkp6$h72$[EMAIL PROTECTED]>, Cameron Hutchison
>> <[EMAIL PROTECTED]> wrote:
>>
>> > Consider this:
>> >
>> > #define inc(x) (++(x))
>> > ...
>> > int x = 1;
>> > ...
>> > inc(x);
>> >
>> > In this case, x is being modified and you cannot tell from the context. It
>> > may be bad form to write a macro with lower case letters, but it can also
>> > be argued that it is bad form to use non-const references in C++.
>>
>> A hit! A very palpable hit!
>
>Right, but you called the macro/function inc. Maybe it would be more
>obvious if the function were named increment?
>
>template<class T>
>inline T& increment(T& x) {
> return ++x;
>}
>
>Is there any question as to whether increment(y) changes the value of y?
That is certainly a step in the right direction, but to answer your
question: Yes, _indeed there is_ a question as to whether increment(y)
changes the value of y?
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Re: GNU make help
Date: 02 Jul 1999 16:23:18 -0400
Reply-To: [EMAIL PROTECTED]
%% "Frank V. Castellucci" <[EMAIL PROTECTED]> writes:
fvc> %$(O):%.cpp
fvc> @echo In compilation for target in $(OSTYPE)
fvc> [compile statement using builtin variables [e.g. $(CXX) etc...]
fvc> including -o $(OUTOBJDIR)/$@
fvc> When running make, _all, dispcomp, and cleanchk are run but the
fvc> compile for test is not run. In other words, obj is never
fvc> evaluated.
Hmm. I'm sure it is being evaluated. Maybe the problem is you have a
"test.o" in the source directory? That would keep make from doing
anything.
Basically, you have written an illegal rule here. It's not allowed for
you do something like:
%.o : %.c
cc -o <some-other-dir>/$@ $<
IOW, you _MUST_ create a target with the _exact_ name "$@". If you
don't, your rule is invalid and make will not work the way you expect.
fvc> I guess what I would like is to: 1. Setup something
fvc> that tells make to look into $(OUTOBJDIR) when evaluating the
fvc> target [test.o] file. 2. While I am at it, have additional
fvc> header, source, obj, etc directories dynamically added to
fvc> resolution of files.
fvc> Any help would be appreciated. I looked through info make to no
fvc> avail.
You may find the various discussions on VPATH, etc. enlightening; see:
http://www.ultranet.com/~pauld/gmake/
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 2 Jul 1999 13:44:21 -0700
Timo Tossavainen <[EMAIL PROTECTED]> wrote:
>Your Lisp-bashing has gone a bit too far.
I have not bashed Lisp. I have not seen any bashing of Lisp here.
The subject is C++, and I have posted correcting falsehoods
written about C++. It happens that Lisp doesn't meet my needs,
but it doesn't seem to have been meant to. That's OK.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
