6

Why would you do

g++ -Wall -I/usr/local/include/thrift *.cpp -lthrift -o something

instead of:

g++ -Wall -I/usr/local/include/thrift -c Something.cpp -o something.o
g++ -Wall -I/usr/local/include/thrift -c Something_server.cpp -o server.o
g++ -Wall -I/usr/local/include/thrift -c your_thrift_file_constants.cpp -o constants.o
g++ -Wall -I/usr/local/include/thrift -c your_thrift_file_types.cpp -o types.o

and then:

g++ -L/usr/local/lib -lthrift *.o -o Something_server

Am I right that the first step does essentially the same thing as the second sequence?

Also, to make them identical should something be Something_server in the first line?

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
algorithmicCoder
  • 263
  • 1
  • 2
  • 6
  • 4
    Shouldn’t your question be the other way round? As it is, the answer is trivial: “because it’s five times shorter”. – Konrad Rudolph May 24 '11 at 08:33

1 Answers1

18

You're right that you'll end up with the same executable at the end (albeit with a different name); in the first case gcc will actually create a bunch of temporary object files that it removes after linking, versus the second case where you're making the object files yourself.

The main reason to do things the second way is to allow for incremental building. After you've compiled your project once, say you change Something.cpp. The only object file affected is something.o -- there's no reason to waste time rebuilding the others. A build system like make would recognize that and only rebuild something.o before linking all the object files together.

Michael Mrozek
  • 91,316
  • 38
  • 238
  • 232