Best Way to Compile Large Project

[David T. Ashley]

I have a large project on a Linux box that may eventually have several
hundred 'C' source files, which need to be compiled and linked into several
executables.

Not all of the executables will use all of the files (i.e. there would be no
linker references to some symbols).

The project will naturally be broken down into several or more
subdirectories.

Questions:

a)What is the best way in general to build? Compile all the .c files into
corresponding .o files, and then link the .o files explicitly?

b)Any thoughts on doing this with "make"?

c)Any thoughts on the limitations of the linker?

Thanks.

[Pascal Bourguignon]

"David T. Ashley" <dt*@e3ft.comwrites:

I have a large project on a Linux box that may eventually have several
hundred 'C' source files, which need to be compiled and linked into several
executables.

Not all of the executables will use all of the files (i.e. there would be no
linker references to some symbols).

The project will naturally be broken down into several or more
subdirectories.

Questions:

a)What is the best way in general to build? Compile all the .c files into
corresponding .o files, and then link the .o files explicitly?

Yes. An alternative, if the project is big, with subparts evolving at
different paces, would be to make libraries of subprojects (modules).

Also, it could be faster to build the libraries and link several
programs with a choice of these libraries, rather than linking these
programs from all the object files everytime. (Better benchmark it,
it'd depend on the project).

b)Any thoughts on doing this with "make"?

Yes. But read this first:

http://members.canb.auug.org.au/~mil...cons-harm.html

ie. use only one Makefile.

c)Any thoughts on the limitations of the linker?

None. I've got an empty brain. Sorry.
--
__Pascal Bourguignon__ http://www.informatimago.com/

"Specifications are for the weak and timid!"

[dcorbit]

David T. Ashley wrote:

I have a large project on a Linux box that may eventually have several
hundred 'C' source files, which need to be compiled and linked into several
executables.

Not all of the executables will use all of the files (i.e. there would be no
linker references to some symbols).

The project will naturally be broken down into several or more
subdirectories.

Questions:

a)What is the best way in general to build? Compile all the .c files into
corresponding .o files, and then link the .o files explicitly?

b)Any thoughts on doing this with "make"?

c)Any thoughts on the limitations of the linker?

Thanks.

<OT>
Have you tried Eclipse and CDT?
http://www.eclipse.org/
http://www.eclipse.org/cdt/
</OT>

[Barry]

"David T. Ashley" <dt*@e3ft.comwrote in message
news:nB*******************@fe178.usenetserver.com. ..

I have a large project on a Linux box that may eventually have several
hundred 'C' source files, which need to be compiled and linked into

several

executables.

Not all of the executables will use all of the files (i.e. there would be

no

linker references to some symbols).

The project will naturally be broken down into several or more
subdirectories.

Questions:

a)What is the best way in general to build? Compile all the .c files into
corresponding .o files, and then link the .o files explicitly?

b)Any thoughts on doing this with "make"?

c)Any thoughts on the limitations of the linker?

Thanks.

Build tools are off topic for clc, but you could start by looking
at make. The last time some of the folks on this board tried to
respond to a questions about "make" several showed they had
noclue Best done by a search and use of your man pages.

<<OT>>
If you have a fully installed development environment you may
take a look at autoconf and automake. But, they come with
caveats with you should look at as well, which may lead you
to better tools.
<</OT>>

[Henrik Goldman]

b)Any thoughts on doing this with "make"?

>

We're in a situation much like your own. More then 100 files, at least 10
applications build from both our "framework" code and application specific
code.

If you consider make then try out makepp instead:
http://makepp.sourceforge.net/

I've used it for like 3 years for now and don't regret it at all!
It's suppose to be a make replacement and it solves several issues that make
has.
E.g. it has an automatic dependency scanner and I've never suffered from
files which were not correctly recompiled.
Also it won't need recursing (in most cases) like traditional make.

Besides you can write extra scripts for it in perl.

The downside is though that it's a bit slower since it's written in perl.
However this is a cheap price to pay. Also the latest build from CVS is
nessecary but not always stable. I've contributed with alot of feedback to
the project so far but usually it's only for the better.

One more thing is that it's very portable. We use it on Windows, Linux,
Macosx, Solaris, AIX and HP-UX and also support several cross compilers
without additional scripts or applications.

At least if you consider make then give this one a try.

-- Henrik

[Stefaan A Eeckels]

On Wed, 27 Dec 2006 22:11:31 -0500
"David T. Ashley" <dt*@e3ft.comwrote:

I have a large project on a Linux box that may eventually have
several hundred 'C' source files, which need to be compiled and
linked into several executables.

That's not a large project :)

Not all of the executables will use all of the files (i.e. there
would be no linker references to some symbols).

Then you should consider using shared objects (.so libraries).

The project will naturally be broken down into several or more
subdirectories.

One hopes so. Also consider using a version control system. Subversion
is pretty neat and a doddle to set up.

Questions:

a)What is the best way in general to build? Compile all the .c files
into corresponding .o files, and then link the .o files explicitly?

See above. One would normally group the related functions into shared
libraries, and then link the various programs against these libraries.
Just linking everything statically is so twentieth century, dear :)

>
b)Any thoughts on doing this with "make"?

Make is the time-honoured way to do this. You need to spend some time
mastering its syntax, but once you know how to use it, make is a very
powerful tool. There are alternatives to make, but they have their own
limitations and idiosyncrasies, in addition to being niche products.

c)Any thoughts on the limitations of the linker?

Unless you have some specific requirements you did not mention, rest
assured that for a project like yours (building a few executables from
a moderate number of source files) the Unix linkers have no
limitations.

--
Stefaan A Eeckels
--
"We have gone from a world of concentrated knowledge and wisdom to one
of distributed ignorance. And we know and understand less while being
increasingly capable." Prof. Peter Cochrane, formerly of BT Labs
(With thanks to Brian Hamilton Kelly)

[toby]

Barry wrote:

"David T. Ashley" <dt*@e3ft.comwrote in message
news:nB*******************@fe178.usenetserver.com. ..

I have a large project on a Linux box that may eventually have several
hundred 'C' source files, which need to be compiled and linked into

several

executables.

Not all of the executables will use all of the files (i.e. there would be

no

linker references to some symbols).

The project will naturally be broken down into several or more
subdirectories.

Questions:

a)What is the best way in general to build? Compile all the .c files into
corresponding .o files, and then link the .o files explicitly?

b)Any thoughts on doing this with "make"?

Yes.

c)Any thoughts on the limitations of the linker?

Thanks.

Build tools are off topic for clc, but you could start by looking
at make. The last time some of the folks on this board tried to
respond to a questions about "make" several showed they had
noclue Best done by a search and use of your man pages.

What also tends to be revealed by make *questions* is that the
questioner has not read 'info make'[1], which should a first step to
any serious use of it.

[1] Online here: http://www.gnu.org/software/make/manual/make.html

>
<<OT>>
If you have a fully installed development environment you may
take a look at autoconf and automake. But, they come with
caveats with you should look at as well, which may lead you
to better tools.
<</OT>>

[jussij]

David T. Ashley wrote:

b)Any thoughts on doing this with "make"?

IMHO once any project grows to anything over one or two files,
using make is the only way to go.

Also if you take a little bit of time to understand make files:

http://www.zeusedit.com/forum/viewtopic.php?t=300

you'll find make is pretty easy to use.

Jussi Jumppanen
Author: Zeus for Windows
http:\\www.zeusedit.com

[Logan Shaw]

toby wrote:

What also tends to be revealed by make *questions* is that the
questioner has not read 'info make'[1], which should a first step to
any serious use of it.

Provided you have a specific reason to use GNU make. If not, then
reading some documentation that isn't GNU-specific might be a better
idea.

- Logan

[Logan Shaw]

ju****@zeusedit.com wrote:

Jussi Jumppanen
Author: Zeus for Windows
http:\\www.zeusedit.com

^^

I'm sure you meant to give a legal URI there...

- Logan

[james of tucson]

dc*****@connx.com wrote:

>
<OT>
Have you tried Eclipse and CDT?
http://www.eclipse.org/
http://www.eclipse.org/cdt/
</OT>

While I love, absolutely adore, using Eclipse for Java, my brief
encounter with CDT made me *run* back to the shelter of vim + make.

To be fair, I have put rather substantial effort into tuning my vim
environment for C coding in particular, making the
edit-compile-run-debug cycle much more pleasant than it might appear to
a newbie during his first years with the platform.

[james of tucson]

Logan Shaw wrote:

toby wrote:

>What also tends to be revealed by make *questions* is that the
questioner has not read 'info make'[1], which should a first step to
any serious use of it.

Provided you have a specific reason to use GNU make. If not, then
reading some documentation that isn't GNU-specific might be a better
idea.

- Logan

The OP did specify Linux, not that it necessarily indicates GNU make,
but it is a very safe bet.

[Richard Bos]

Logan Shaw <ls**********@austin.rr.comwrote:

ju****@spamedit.com wrote:

Jussi Jumppanen
Author: Spam for Windows
http:\\www.spamedit.com

^^

I'm sure you meant to give a legal URI there...

I'm sure it just wanted to spam. (And apparently his product "is Y2K",
according to his FAQ. No, not Y2K-compatible; "Y2K". My confidence in
its excellence is not stellar.)

Richard

[toby]

Logan Shaw wrote:

toby wrote:

What also tends to be revealed by make *questions* is that the
questioner has not read 'info make'[1], which should a first step to
any serious use of it.

Provided you have a specific reason to use GNU make. If not, then
reading some documentation that isn't GNU-specific might be a better
idea.

I'd go further and suggest they *should* use GNU make (and read that
manual). But as James says, it's the default 'make' on Linux and OS X
anyway (and bundled as 'gmake', Solaris 10).

>
- Logan

[Default User]

Richard Bos wrote:

Logan Shaw <ls**********@austin.rr.comwrote:

ju****@spamedit.com wrote:

Jussi Jumppanen
Author: Spam for Windows
http:\\www.spamedit.com

^^

I'm sure you meant to give a legal URI there...

I'm sure it just wanted to spam. (And apparently his product "is Y2K",
according to his FAQ. No, not Y2K-compatible; "Y2K". My confidence in
its excellence is not stellar.)

Mr. Jumppanen a well-known figure on many other programming and
compiler newsgroups. I think you've probably done him a disservice my
labeling him a spammer.


Brian

[toby]

james of tucson wrote:

dc*****@connx.com wrote:

<OT>
Have you tried Eclipse and CDT?
http://www.eclipse.org/
http://www.eclipse.org/cdt/
</OT>

While I love, absolutely adore, using Eclipse for Java, my brief
encounter with CDT made me *run* back to the shelter of vim + make.

I avoid CDT's "Managed" mode, not because I have had a bad experience,
but because I prefer make myself - and CDT's "Standard" mode works
perfectly with ordinary makefiles. You even get an pretty outlining
Makefile editor.

>
To be fair, I have put rather substantial effort into tuning my vim
environment for C coding in particular, making the
edit-compile-run-debug cycle much more pleasant than it might appear to
a newbie during his first years with the platform.

[Diwa]

David T. Ashley wrote:

I have a large project on a Linux box that may eventually have several
hundred 'C' source files, which need to be compiled and linked into several
executables.

b)Any thoughts on doing this with "make"?

Check out www.scons.org

[David T. Ashley]

"toby" <to**@telegraphics.com.auwrote in message
news:11*********************@h40g2000cwb.googlegro ups.com...

>
What also tends to be revealed by make *questions* is that the
questioner has not read 'info make'[1], which should a first step to
any serious use of it.

I'm very familiar with make. Just that I wanted to know:

a)Are there any limitations of make that will make it unsuitable for a very
large project?

b)Are there any better alternatives?

Thanks.

[toby]

David T. Ashley wrote:

"toby" <to**@telegraphics.com.auwrote in message
news:11*********************@h40g2000cwb.googlegro ups.com...

What also tends to be revealed by make *questions* is that the
questioner has not read 'info make'[1], which should a first step to
any serious use of it.

I'm very familiar with make. Just that I wanted to know:

a)Are there any limitations of make that will make it unsuitable for a very
large project?

100 source files is not a large project.

>
b)Are there any better alternatives?

Thanks.

[Keith Thompson]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Logan Shaw <ls**********@austin.rr.comwrote:

>ju****@spamedit.com wrote:

Jussi Jumppanen
Author: Spam for Windows
http:\\www.spamedit.com

^^

I'm sure you meant to give a legal URI there...

I'm sure it just wanted to spam. (And apparently his product "is Y2K",
according to his FAQ. No, not Y2K-compatible; "Y2K". My confidence in
its excellence is not stellar.)

The contents of signatures are not bound by topicality rules, and I
have no problem with advertisements there. But a signature should be
delimited by the standard "-- " line.

(If you're interested in the actual URL, go back to Jussi's article;
it was altered in followups. There is no "spamedit.com"; when I
Googled for "spamedit", it asked me if I meant "someidiot".)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Stefaan A Eeckels]

On Fri, 29 Dec 2006 13:19:57 -0500
"David T. Ashley" <dt*@e3ft.comwrote:

"toby" <to**@telegraphics.com.auwrote in message
news:11*********************@h40g2000cwb.googlegro ups.com...

What also tends to be revealed by make *questions* is that the
questioner has not read 'info make'[1], which should a first step to
any serious use of it.

I'm very familiar with make. Just that I wanted to know:

a)Are there any limitations of make that will make it unsuitable for
a very large project?

You are not familiar with make :)

b)Are there any better alternatives?

For certain values of better. Make is pretty good at what it does, but
it rubs many people the wrong way. As a result, many people have
developed alternatives. They are sometimes better. Mostly they are
worse. If you have a pet gripe with make, then _you_ should research
alternatives that don't have that particular issue.

--
Stefaan A Eeckels
--
Microsoft treats IT managers the way Proctor & Gamble treats
nine-year-old prospective consumers: lots of noise, bright colors, and
jumping around. Other software vendors just wish they could be so
successful. -- Cameron Laird in comp.lang.tcl

[David T. Ashley]

Stefaan A Eeckels wrote:

>
You are not familiar with make :)

make is that dog of a program dating back to at least the 1980's where
you specify targets, actions, and dependencies, right?

And there are some extra goodies thrown in so that modifying a makefile
is easier (i.e. configuration items in one place) and so that commands
like "make check", "make clean" etc. are possible?

Did I miss anything?

What makes you think I'm not familiar with make?

P.S.--I really didn't need to make this post. I'm just testing Mozilla
as a newsgroup reader. Microsoft Outlook Express seems to have some
annoying bugs. So, if anyone has recommendations ...
------------------------------------------------------------
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[Pascal Bourguignon]

"David T. Ashley" <dt*@e3ft.comwrites:

Stefaan A Eeckels wrote:

>>
You are not familiar with make :)

make is that dog of a program dating back to at least the 1980's where
you specify targets, actions, and dependencies, right?

And there are some extra goodies thrown in so that modifying a
makefile is easier (i.e. configuration items in one place) and so that
commands like "make check", "make clean" etc. are possible?

Did I miss anything?

What makes you think I'm not familiar with make?

Well, some familiarity with make would let you know that make is used
for most software projects, including the bigest open source ones. If
make is good enough for a ~24000-file Linux project or a ~42000-file
Mozilla project, what makes you think that it won't be good enough for
your 100-file software project?
--
__Pascal Bourguignon__ http://www.informatimago.com/

"Specifications are for the weak and timid!"

[Mark McIntyre]

On Fri, 29 Dec 2006 13:19:57 -0500, in comp.lang.c , "David T. Ashley"
<dt*@e3ft.comwrote:

>I'm very familiar with make. Just that I wanted to know:

a)Are there any limitations of make that will make it unsuitable for a very
large project?

"make" isn't part of C, so in the context of CLC, this question is
essentially offtopic. However IME for large projects (say with a few
tens of libraries with interdependencies) you need something more
sophisticated.

>b)Are there any better alternatives?

yes. A general programming group can probably advise.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.netwrites:

On Fri, 29 Dec 2006 13:19:57 -0500, in comp.lang.c , "David T. Ashley"
<dt*@e3ft.comwrote:

>>I'm very familiar with make. Just that I wanted to know:

a)Are there any limitations of make that will make it unsuitable for a very
large project?

"make" isn't part of C, so in the context of CLC, this question is
essentially offtopic. However IME for large projects (say with a few
tens of libraries with interdependencies) you need something more
sophisticated.

Yes -- but some of those more sophisticated solutions work on top of
"make". For example, there are systems that automatically generate a
Makefile from some higher-level description.

>>b)Are there any better alternatives?

yes. A general programming group can probably advise.

Such as comp.unix.programmer or, if you're not restricting yourself to
Unix-like systems, comp.programmer.

I see that this is already cross-posted to comp.unix.programmer, so
I'll redirect followups there.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Bos]

"Default User" <de***********@yahoo.comwrote:

Richard Bos wrote:

Logan Shaw <ls**********@austin.rr.comwrote:

ju****@spamedit.com wrote:
Jussi Jumppanen
Author: Spam for Windows
http:\\www.spamedit.com
^^
I'm sure you meant to give a legal URI there...

I'm sure it just wanted to spam. (And apparently his product "is Y2K",
according to his FAQ. No, not Y2K-compatible; "Y2K". My confidence in
its excellence is not stellar.)

Mr. Jumppanen a well-known figure on many other programming and
compiler newsgroups. I think you've probably done him a disservice my
labeling him a spammer.

He may post the most worthwhile posts elsewhere, and in those groups he
will not be a spammer but a well-received contributor; but in
comp.lang.c, I've never seen him post anything else except
advertisements for his editor, as he's done twice recently.

Richard

[Default User]

Richard Bos wrote:

"Default User" <de***********@yahoo.comwrote:

Mr. Jumppanen a well-known figure on many other programming and
compiler newsgroups. I think you've probably done him a disservice
my labeling him a spammer.

He may post the most worthwhile posts elsewhere, and in those groups
he will not be a spammer but a well-received contributor; but in
comp.lang.c, I've never seen him post anything else except
advertisements for his editor, as he's done twice recently.

Did you fail to notice that this thread is cross-posted to
comp.unix.programmer?


Brian

[Al Balmer]

On 3 Jan 2007 22:48:23 GMT, "Default User" <de***********@yahoo.com>
wrote:

>Richard Bos wrote:

>"Default User" <de***********@yahoo.comwrote:

Mr. Jumppanen a well-known figure on many other programming and
compiler newsgroups. I think you've probably done him a disservice
my labeling him a spammer.

He may post the most worthwhile posts elsewhere, and in those groups
he will not be a spammer but a well-received contributor; but in
comp.lang.c, I've never seen him post anything else except
advertisements for his editor, as he's done twice recently.

Did you fail to notice that this thread is cross-posted to
comp.unix.programmer?

Do you mean that it's OK to spam c.l.c. as long as you also spam
c.u.p.?

--
Al Balmer
Sun City, AZ

[Default User]

Al Balmer wrote:

On 3 Jan 2007 22:48:23 GMT, "Default User" <de***********@yahoo.com>
wrote:

Richard Bos wrote:

"Default User" <de***********@yahoo.comwrote:

Mr. Jumppanen a well-known figure on many other programming and
compiler newsgroups. I think you've probably done him a

disservice my labeling him a spammer.

>
He may post the most worthwhile posts elsewhere, and in those

groups >he will not be a spammer but a well-received contributor;
but in >comp.lang.c, I've never seen him post anything else except

advertisements for his editor, as he's done twice recently.

Did you fail to notice that this thread is cross-posted to
comp.unix.programmer?

Do you mean that it's OK to spam c.l.c. as long as you also spam
c.u.p.?

Richard was talking about what Jussi posted to clc. The point is that
likely he posted it to cup. I don't know if it's on-topic or not there,
I don't presume to speak for another group.

Personally, I don't believe he was guilty of spamming here either. He
answered the question with a reference to a forum thread, which is in
my opinion valid. The so-called "spam" consists of an improperly
demarcated signature. In no way did it seem to me like that was posted
as the answer to the question. Yes, Jussi needs to correct that and get
a proper delimiter for his signature, but no he didn't spam either
group.

I think Richard was way off-base. I think you're horning in without
really reviewing the situation. Anyone else I can slag while I'm at it?
Navia! It's all his fault, I'm sure.

Brian

[CBFalconer]

Default User wrote:

Al Balmer wrote:

>"Default User" <de***********@yahoo.comwrote:

>>Richard Bos wrote:
"Default User" <de***********@yahoo.comwrote:

Mr. Jumppanen a well-known figure on many other programming
and compiler newsgroups. I think you've probably done him a

disservice my labeling him a spammer.

Your newsreader is seriously fouling the quoted material.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Default User]

CBFalconer wrote:

Default User wrote:

Al Balmer wrote:

"Default User" <de***********@yahoo.comwrote:
Richard Bos wrote:
"Default User" <de***********@yahoo.comwrote:
>
Mr. Jumppanen a well-known figure on many other programming
and compiler newsgroups. I think you've probably done him a
disservice my labeling him a spammer.

Your newsreader is seriously fouling the quoted material.

That happens sometimes when the quotes get too deep.

Brian