How best to provide a module

[James Harris]

If distributing a piece of code in C how is it best to provide it?
Options seem to be

1. Precompile the module.c file(s) to module.o and provide a header.
The using code then has

#include "module.h"

at the top and needs to be linked with the compiled module.

2. Include the source directly. The using code then has

#include "module.c"

at the lowest lexical level - i.e. not within a function. Are both of
these viable ways to include a separate piece of source code and and
are there any others?

 

[James Harris]

James Harris said: ....


But that's *not* another way! At least, it's a lousy, lousy idea. If
you're okay with the user having the source, just send them the source
(which you'd have to do anyway, for the above to "work"), and either rely
on them to, or tell them how to, compile it and link it into their
project. (You shouldn't need to tell them unless they're very new to C.)

Haha! I've not seen anyone do this. But why is it always lousy? And
are there no circumstances where it would be good?

 

[Wolfgang Draxinger]

Haha! I've not seen anyone do this. But why is it always lousy?

Because it means, that you can include that module into only one
source file. If you include it multiple times, that you got a
bunch of object files all with the same identifiers clashing at
link time.

And are there no circumstances where it would be good?

No. Either provide a separate header, or just provide the source
file and let the other people extract a header with a bunch of
PERL code.

Wolfgang Draxinger

 

[James Harris]

It can cause problems with duplicate definitions.
ok


Never say never.

But I recommend not to do it without some compelling
reason.

Agreed.

 

[Keith Thompson]

If distributing a piece of code in C how is it best to provide it?
Options seem to be

1. Precompile the module.c file(s) to module.o and provide a header.
The using code then has

#include "module.h"

at the top and needs to be linked with the compiled module.

That can work, but only if the module.o file is compatible with the
user's system. You could provide multiple versions of module.o for
different systems. It's a pain, but it's pretty much necessary if you
don't want to distribute your source code.

You might also consider distributing shrouded C source. There are
utilities that will automatically obfuscate C source code, so it will
still compile and have the same semantics but is practically very
difficult to read or modify.

But if you don't mind distributing your sources (and your second idea
suggests you don't), then you probably shouldn't bother.

2. Include the source directly. The using code then has

#include "module.c"

at the lowest lexical level - i.e. not within a function. Are both of
these viable ways to include a separate piece of source code and and
are there any others?

Bad idea. Just distribute two files, module.h and module.c.

 

[Bartc]

If distributing a piece of code in C how is it best to provide it?
Options seem to be

1. Precompile the module.c file(s) to module.o and provide a header.
The using code then has

#include "module.h"

at the top and needs to be linked with the compiled module.

2. Include the source directly. The using code then has

#include "module.c"

at the lowest lexical level - i.e. not within a function. Are both of
these viable ways to include a separate piece of source code and and
are there any others?

3. Precompile into a dynamic library. Distribute the library plus a .h file
or docs sufficient to make use of the library.

The format will vary between OSs, but is not so dependent on compiler (or,
to some extent, language).

 

[Stephen Sprunk]

Haha! I've not seen anyone do this. But why is it always lousy? And
are there no circumstances where it would be good?

It may allow some compilers to perform better optimization (such as
inlining) if the entire program is presented as a single translation unit.

S