Complete, and utter automation with Jam

Hi all,

Thanks for all your responses!

Brian said:

> But from his original post, it sounds like he's doing
something EXTREMELY 
> non-standard (and bad). Just to clarify: do you
actually #include all  
> yoursource code (.c files) in a single file!?

Sorry, when I typed the three source files, I accidentally
put #include
in front of them. Instead, the only #include listed in
"main.c" is
"data.h".

> solutions, but they're all really fragile, and will
only work in very 
> constrained situations. Do you have source files in
multiple directories, 
> for example?

Well not at the moment, but of course I may in the future. I
think I can  
see
where you're coming from, but as long as .h and .c files
are kept together,
there shouldn't be a problem. After all, if we can keep
things like  
stdlib.h
and print.h in the source file, and that can compile without
the need of
a makefile, then the same should apply one's own .h files ?


John said:

> How should it "know" to link to data.c ?
> Is this purely by naming convention?

Well the same issue is involved with stdlib.h and print.h,
but they manage
to get round it for some reason.


> There are plenty of cases where XXX.h may be included
and that may mean  
> that
> AAA.c, BBB.c, and DDD.c are the ones it should
"know" to include, but  
> that
> does not have the advantage of a naming convention.

So there is a use to naming the .c files different from the
.h files? Is  
that
something to do with two or more different .c files having
the same set of
function names or variables as one 'master' .h file? Do
you think it would  
be
a good idea to have a naming convention where at least one c
file must be
named the same as each .h file?

This is going a bit off topic, and I could well be mistaken
and maybe  
header
files have some intrinsic use. But I'm wondering if maybe
they are used  
these
days only because otherwise the whole c structure / compiler
situation
would need a rewrite otherwise. Ideally, I think that the
programmer  
should be
able include c files directly into other c files (no .h
files at all). As  
long,
as the compiler (or make) is super intelligent, and doesn't
recompile files
unnecessarily, things should go fine. I could be hopelessly
misguided on  
this,
but I'm sure it's possible in principle, without
compromising any of the  
power
of c/c++.

It's the same principle as having to declare the functions
(a waste of  
time).
Okay it's useful info for the programmer, but ultimately
this should be  
left
to the IDE enviroment to display for automation.

Cheers, Daniel
http://www.skytopia.com
_______________________________________________
jamming mailing list  -  jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

> > How should it "know" to link to data.c
?
> > Is this purely by naming convention?
>
> Well the same issue is involved with stdlib.h and
print.h, but they manage
> to get round it for some reason.

When you #include stdlib.h, you are not getting any source
code, just
definitions of functions / etc.
The actual code is compiled in a static library, which is
typically
linked in by default so you don't have to specify it
manually.
What I mean is that there is no "stdlib.c" file
that gets
automatically put along with your sources.
In fact, the functions in stdlib.h are defined in a variety
of
different .c files - the rand() function is in rand.c,
strtod() is in
strtod.c, and so on.
They are all compiled into a library so they can be included
as a
single unit by your program.

Thus in response to your question:
> So there is a use to naming the .c files different from
the .h files?

Yes, there is - at least that is how it is done in this copy
of the c
standard library source I have hanging around.

Have you been programming C/C++ for long ?
I have, for instance, seen similar conceptual issues come up
with some
Java programmers when switching to C/C++, as Java has no
notion of
headers/sources.

-John

On 8/19/06, Daniel White <twinbee41skytopia.com> wrote:
> Hi all,
>
> Thanks for all your responses!
>
> Brian said:
>
> > But from his original post, it sounds like he's
doing something EXTREMELY
> > non-standard (and bad). Just to clarify: do you
actually #include all
> > yoursource code (.c files) in a single file!?
>
> Sorry, when I typed the three source files, I
accidentally put #include
> in front of them. Instead, the only #include listed in
"main.c" is
> "data.h".
>
> > solutions, but they're all really fragile, and
will only work in very
> > constrained situations. Do you have source files
in multiple directories,
> > for example?
>
> Well not at the moment, but of course I may in the
future. I think I can
> see
> where you're coming from, but as long as .h and .c
files are kept together,
> there shouldn't be a problem. After all, if we can
keep things like
> stdlib.h
> and print.h in the source file, and that can compile
without the need of
> a makefile, then the same should apply one's own .h
files ?
>
>
> John said:
>
> > How should it "know" to link to data.c
?
> > Is this purely by naming convention?
>
> Well the same issue is involved with stdlib.h and
print.h, but they manage
> to get round it for some reason.
>
>
> > There are plenty of cases where XXX.h may be
included and that may mean
> > that
> > AAA.c, BBB.c, and DDD.c are the ones it should
"know" to include, but
> > that
> > does not have the advantage of a naming
convention.
>
> So there is a use to naming the .c files different from
the .h files? Is
> that
> something to do with two or more different .c files
having the same set of
> function names or variables as one 'master' .h file?
Do you think it would
> be
> a good idea to have a naming convention where at least
one c file must be
> named the same as each .h file?
>
> This is going a bit off topic, and I could well be
mistaken and maybe
> header
> files have some intrinsic use. But I'm wondering if
maybe they are used
> these
> days only because otherwise the whole c structure /
compiler situation
> would need a rewrite otherwise. Ideally, I think that
the programmer
> should be
> able include c files directly into other c files (no .h
files at all). As
> long,
> as the compiler (or make) is super intelligent, and
doesn't recompile files
> unnecessarily, things should go fine. I could be
hopelessly misguided on
> this,
> but I'm sure it's possible in principle, without
compromising any of the
> power
> of c/c++.
>
> It's the same principle as having to declare the
functions (a waste of
> time).
> Okay it's useful info for the programmer, but
ultimately this should be
> left
> to the IDE enviroment to display for automation.
>
> Cheers, Daniel
> http://www.skytopia.com
> _______________________________________________
> jamming mailing list  -  jammingperforce.com
> http://maillist.perforce.com/mailman/listinfo/jamming
>
_______________________________________________
jamming mailing list  -  jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

Hi John,

>> > How should it "know" to link to
data.c ?
>> > Is this purely by naming convention?
>>
>> Well the same issue is involved with stdlib.h and
print.h, but they  
>> manage
>> to get round it for some reason.
>
> When you #include stdlib.h, you are not getting any
source code, just
> definitions of functions / etc.
> The actual code is compiled in a static library, which
is typically
> linked in by default so you don't have to specify it
manually.

Right okay, that makes sense.


> What I mean is that there is no "stdlib.c"
file that gets
> automatically put along with your sources.
> In fact, the functions in stdlib.h are defined in a
variety of
> different .c files - the rand() function is in rand.c,
strtod() is in
> strtod.c, and so on.
> They are all compiled into a library so they can be
included as a
> single unit by your program.

Woudln't it be more space efficient for C to only include
the necessary
functions required for the operation of a particular
program? Mind
you, I suppose the cost would having to recompile the source
each
time...

> Thus in response to your question:
>> So there is a use to naming the .c files different
from the .h files?
>
> Yes, there is - at least that is how it is done in this
copy of the c
> standard library source I have hanging around.
>
> Have you been programming C/C++ for long ?
> I have, for instance, seen similar conceptual issues
come up with some
> Java programmers when switching to C/C++, as Java has
no notion of
> headers/sources.

Rumbled!  Okay,
it's true, I came from a Java background, and
switched to C because of the speed. However, the language D,
which
is an upgrade from C, doesn't bother with them. Hmm... I
wonder why ;)

Dan

>
> -John
>
> On 8/19/06, Daniel White <twinbee41skytopia.com> wrote:
>> Hi all,
>>
>> Thanks for all your responses!
>>
>> Brian said:
>>
>> > But from his original post, it sounds like
he's doing something  
>> EXTREMELY
>> > non-standard (and bad). Just to clarify: do
you actually #include all
>> > yoursource code (.c files) in a single file!?
>>
>> Sorry, when I typed the three source files, I
accidentally put #include
>> in front of them. Instead, the only #include listed
in "main.c" is
>> "data.h".
>>
>> > solutions, but they're all really fragile,
and will only work in very
>> > constrained situations. Do you have source
files in multiple  
>> directories,
>> > for example?
>>
>> Well not at the moment, but of course I may in the
future. I think I can
>> see
>> where you're coming from, but as long as .h and .c
files are kept  
>> together,
>> there shouldn't be a problem. After all, if we can
keep things like
>> stdlib.h
>> and print.h in the source file, and that can
compile without the need of
>> a makefile, then the same should apply one's own
.h files ?
>>
>>
>> John said:
>>
>> > How should it "know" to link to
data.c ?
>> > Is this purely by naming convention?
>>
>> Well the same issue is involved with stdlib.h and
print.h, but they  
>> manage
>> to get round it for some reason.
>>
>>
>> > There are plenty of cases where XXX.h may be
included and that may  
>> mean
>> > that
>> > AAA.c, BBB.c, and DDD.c are the ones it should
"know" to include, but
>> > that
>> > does not have the advantage of a naming
convention.
>>
>> So there is a use to naming the .c files different
from the .h files? Is
>> that
>> something to do with two or more different .c files
having the same set  
>> of
>> function names or variables as one 'master' .h
file? Do you think it  
>> would
>> be
>> a good idea to have a naming convention where at
least one c file must  
>> be
>> named the same as each .h file?
>>
>> This is going a bit off topic, and I could well be
mistaken and maybe
>> header
>> files have some intrinsic use. But I'm wondering
if maybe they are used
>> these
>> days only because otherwise the whole c structure /
compiler situation
>> would need a rewrite otherwise. Ideally, I think
that the programmer
>> should be
>> able include c files directly into other c files
(no .h files at all).  
>> As
>> long,
>> as the compiler (or make) is super intelligent, and
doesn't recompile  
>> files
>> unnecessarily, things should go fine. I could be
hopelessly misguided on
>> this,
>> but I'm sure it's possible in principle, without
compromising any of the
>> power
>> of c/c++.
>>
>> It's the same principle as having to declare the
functions (a waste of
>> time).
>> Okay it's useful info for the programmer, but
ultimately this should be
>> left
>> to the IDE enviroment to display for automation.
>>
>> Cheers, Daniel
>> http://www.skytopia.com
>> _______________________________________________
>> jamming mailing list  -  jammingperforce.com
>> http://maillist.perforce.com/mailman/listinfo/jamming
>>



-- 
www.skytopia.com
_______________________________________________
jamming mailing list  -  jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming