[jamming] Complete, and utter automation with Jam

[John Waugh]

> > 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 <twinbee41 at skytopia.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  -  jamming at perforce.com
> http://maillist.perforce.com/mailman/listinfo/jamming
>