Again with the multiple files

[st_adamin]

I just started using Code::Blocks and really am not too familiar with C++ anyway, but here's my problem.  I can add a new cpp file to my project, give it a header, and include any additional source outside my main.  But only with one extra cpp file.  When I try to add a second file, compilation always fails.

This happens whether I'm doing a windows app or a console app, whether one extra file is for all my openGL code and the other for my SDL code, or simply a couple of dummy classes (File1 Class1 File2 Class2) just to find out if I can actually compile three source files together or not.  I couldn't figure out why my very generic SDL code was failing until I realized it was the third file (two extra above main.cpp).

I can actually add a third source file, and it will compile.  I can even #include the header file for that third file.  But the moment I declare any classes or functions in the header, or define any functions in the source file, I get a compilation error, and it is random.  It may be "error compiling main.o" or error compiling "first_extra_source.o", it just depends on whether I added code to the first or second extra source files (respectively).  None of the code is repeated across (multiple declarations) and all headers are guarded.  It doesn't matter if I "remove from project" the first extra file or the second extra file, when one is deleted, the project compiles.

I've made sure to check "Debug, Release" checkboxes, as that is the only general solution I've found.  Another general solution I found was to directly #include "secondsourcefile.cpp"  This did not seem like a great idea, but i tried it anyway and it did not work.  Surely there is just some setting I missed... What is that setting?  As I said, I am unfamiliar with c++ so it could be that I'm not getting something inherent to the process of creating 'large' projects.  According to the first two pages of google, multiple files in CodeBlocks should be automatic now, but it may not be.  Do I need to figure out how to do this manually?

Remember, I've had several projects work with one additional file, no questions asked, with no change to my method of setting up a new project, and I've tried to do this four different ways just to finally ensure that it is not bad code (just in case).

Any help would be most appreciated.  I finally got my SDL libraries working with borland and have made it through Nehe tutorial 5 with the addition of a joystick.  I want to move on to something fun, but I really don't want 12,000 lines of code in one file.  I've made the mistake before and I don't ever want to again 

Pertinent details:
Code::Blocks 8.02
Borland BCC55 Free Command Line
Windows 7

[st_adamin]

Having turned on full compiler logging as was pointed out to someone else, I get:

Compiling: Class2.cpp
Class2.cpp:
Compiling: main.cpp
main.cpp:
Compiling: Class1.cpp
Class1.cpp:
Linking console executable: bin\Debug\TestingThreeSources.exe
Error: Error processing module main.cpp
Process terminated with status 2 (0 minutes, 0 seconds)
0 errors, 0 warnings

Zero errors and zero warnings.  But it is definitely not rebuilding...

[stahta01]

Having turned on full compiler logging as was pointed out to someone else, I get:

Please try again to turn on full compiler logging; you did NOT post a build log with it turned on.

Possible causes you are using a different compiler then the one you changed the settings on.

Tim S.

[st_adamin]

Haha, good guess on the "possible cause."  I've actually made the mistake of changing settings on GCC not Borland C++ a couple times.  I thought I was over that now.


-------------- Build: Debug in TestingThreeSources ---------------

bcc32.exe -q -w -x  -v    -IC:\Borland\BCC55\Include  -oobj\Debug\Class2.obj -c Class2.cpp
Class2.cpp:
bcc32.exe -q -w -x  -v    -IC:\Borland\BCC55\Include  -oobj\Debug\main.obj -c main.cpp
main.cpp:
bcc32.exe -q -w -x  -v    -IC:\Borland\BCC55\Include  -oobj\Debug\Class1.obj -c Class1.cpp
Class1.cpp:
ilink32.exe -q -ap  -v  -LC:\Borland\BCC55\Lib -LC:\Borland\BCC55\Lib\PSDK  c0x32 obj\Debug\Class2.obj obj\Debug\main.obj obj\Debug\Class1.obj ,bin\Debug\TestingThreeSources.exe,,cw32mt.lib import32.lib ,,
Error: Error processing module main.cpp
Process terminated with status 2 (0 minutes, 0 seconds)
0 errors, 0 warnings


Just for good measure, here it is after removing the Class1.cpp and commenting out any references to Class1


-------------- Build: Debug in TestingThreeSources ---------------

bcc32.exe -q -w -x  -v    -IC:\Borland\BCC55\Include  -oobj\Debug\main.obj -c main.cpp
main.cpp:
bcc32.exe -q -w -x  -v    -IC:\Borland\BCC55\Include  -oobj\Debug\Class2.obj -c Class2.cpp
Class2.cpp:
ilink32.exe -q -ap  -v  -LC:\Borland\BCC55\Lib -LC:\Borland\BCC55\Lib\PSDK  c0x32 obj\Debug\main.obj obj\Debug\Class2.obj ,bin\Debug\TestingThreeSources.exe,,cw32mt.lib import32.lib ,,
Output size is 142.00 KB
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings

Successful rebuild.

[stahta01]

Does anyone have Borland BCC55 Free Command Line working under Windows 7?

I will try it at home in the next week to see if it works under Windows 7; may not have time till Saturday.

Does either class depend on the other class existing?

I suggest trying to up the build priority on the main.cpp.
IIRC, right click on file and under properties is a 0 to 10 scale adjust so main.cpp is before either class in the link list.

Tim S.

[st_adamin]

That got it, thanks.  It actually took a 'lowest priority' build on main.cpp (highest weight - lowest priority) so that it was the last thing built.  When I had main as highest priority, it terminated with a link violation.

No, neither file depends on the other, but I'm going to venture a guess that if they do in the future, the one 'depended upon' will probably need to go first, then the one that makes use of it, then the main. 

Like I said, I'm not too up on c++, but I sort *thought* that was part of the reason headers were used, something about saving "holes" in the code so that after completion the linker would tie the different modules together in the right places... I guess that's simplistic.  I would also guess that if its not working, that's almost the fault of Borland.

I didn't have any problem setting up Borland on Win7 though, other than the Win32 Template Application (the resource file specifically, I had to delete the font size and font; error:BEGIN expected).  But in searching that error, it seemed that some of the templates were "faulty."  I suppose if I were more familiar with windows apps in c++, I probably would have been able to more accurately diagnose the issue.  C# is danged convenient, but I wanted to move to something more portable, and for that matter more "fair."

Thanks a lot, Tim.

Adam