forcing Code::Blocks to put all .o files in same directory

[davemalham]

Hi,
   Very new to Code::Blocks but have been programming for a long time. Is there a simple way to make C::B put all the object files it generates into one directory (where the .exe or .dll goes, for example) rather than into the same directories as the source files? This would make gdb much easier to use when debugging a .dll running in a host application (specifically a VST audio plugin). Environment;
Windoze XP, gcc+ (latest stable), gdb 6.8

   Thnx in advance
                           Dave

[Jenna]

Right-click your project in "Manager"  chose "Properties -> Build targets" and change the text-box "Objects output dir:" as you need it.

[davemalham]

Right-click your project in "Manager"  chose "Properties -> Build targets" and change the text-box "Objects output dir:" as you need it.

Hi Jens,
Hmm, well, I already did that  - it's currently set to "C:\Documents and Settings\Dave\My Documents\VSTPlugins\debug" (I've tried relative as well). What happens is that C::B builds a directory structure in there which mimics the structure of the project's folders and puts the .o files in there, rather than at the top level of \debug. So, if I build, for instance, the VST minihost application, who's source files are in C:\Documents and Settings\Dave\My Documents\vstsdk2.4\public.sdk\samples\vst2.x\minihost\source on my system, the minihost.exe executable correctly gets put in the top level of \debug but C::B adds a new directory structure of \minihost\source to the \debug directory and puts the .o's in there....

[davemalham]

 !!*$@#&! I've come in to work this morning and (once again) deleted all the "spurious" directories in my /debug folder, rebuilt the project and gdb has suddenly started working, finding all the files, symbols and everything BUT I'd swear I haven't done anything I haven't done before and C::B still builds this directory structure in my /debug  folder which mimics the structure of the project's folders and puts the .o files in there - perhaps if I wait till Monday and try again then

Right-click your project in "Manager"  chose "Properties -> Build targets" and change the text-box "Objects output dir:"

might work  :lol:

Seriously, it worries me that I don't know why it started working and it's clear, looking round the forums, that a lot of people are having similar problems with debugging - it's not confined to C::B as DevC++ also seems to be a bit problematic. Now, the main reason for me looking at C::B is to evaluate it as a cross-platform IDE for students with relatively little programming experience to use when developing VST audio plugins (and pd, Ladspa, etc) so I would really appreciate any hints which might help me track this down so that I can be more confident of being able to supply a hassle-free environment for my students.

[MortenMacFly]

C::B still builds this directory structure in my /debug  folder which mimics the structure of the project's folders and puts the .o files in there - perhaps if I wait till Monday and try again then

This is by design. Consider the following project layout:

prj
- func1:
  - interfaces.cpp
- func2:
  - interfaces.cpp


You would not be able to compile this project with a flat object folder. That's exactly why sub-folders need and are being created.

[davemalham]

C::B still builds this directory structure in my /debug  folder which mimics the structure of the project's folders and puts the .o files in there - perhaps if I wait till Monday and try again then

This is by design. Consider the following project layout:

prj
- func1:
  - interfaces.cpp
- func2:
  - interfaces.cpp

You would not be able to compile this project with a flat object folder. That's exactly why sub-folders need and are being created.

Hi,
   I can see the usefulness of that, tho' I would personally be concerned by a project structure of that sort (I'm absolutely certain I would soon start confusing the different interfaces.cpp files) but, unless I am misunderstanding what you are saying, I would just rename the files to something like interfaces_f1.cpp and interfaces_f2.cpp. Setting that aside as it's really just a matter of personal preferences, wouldn't it be possible to have an option to do a flat compile, at least when an object file directory is explicitly given in the target properties. I started having a look at the C::B code last night with a view to adding that myself, but with the system starting to work this morning, I guess that isn't going to happen 

However, I do still need to get to the bottom of why it (gdb) wasn't working yesterday and is this morning on what, AFAICS, is the same project set-up. A colleague has suggested that this morning's m$ auto-update might have something to do with it, but I can't see that myself and unfortunately I did not keep a copy of the earlier .cdb file to check this. (Actually, strictly speaking, gdb was working yesterday, but only if I explicitly loaded the VST plugins files into gdb using the debug menu "send user command" function).

                  Dave

[MortenMacFly]

unless I am misunderstanding what you are saying, I would just rename the files to something like interfaces_f1.cpp and interfaces_f2.cpp.

Well - if you imagine func1 and func2 being actually a part of a 3rd party library (possibly coming from an external, non-self-managed repository) you cannot just rename these files. And in fact we have exactly that issue within the C::B project... just search for duplicate file names. ;-)

[davemalham]

unless I am misunderstanding what you are saying, I would just rename the files to something like interfaces_f1.cpp and interfaces_f2.cpp.

Well - if you imagine func1 and func2 being actually a part of a 3rd party library (possibly coming from an external, non-self-managed repository) you cannot just rename these files. And in fact we have exactly that issue within the C::B project... just search for duplicate file names. ;-)

Okay, now I see the raison d'etre, and it makes a lot of sense - I hadn't been thinking on those lines. However, I still think it would be a useful option to be able to select for a flat compile for simple projects like the ones I'm dealing with so maybe I'll dig through the C::B sources a bit more and see if I can add this myself (all hints gratefully accepted). Meantime I'm still puzzled as to why it started working all of a sudden... :?

[mandrav]

I know it's not in the most prominent place but it is really an advanced option so it's kinda hidden away.

Go "Settings->Compiler->["Other settings" tab]" and click "Advanced options". In the dialog that pops up, go to the "Others" tab and look near the bottom:

• Use flat objects, and
• Use full paths for source files (GDB workaround)

The first one "flattens" the object file (e.g. "src/main.o" becomes "src_main.o") and the second one uses full paths for compiling so GDB can find the source files no matter what...

[davemalham]

I know it's not in the most prominent place but it is really an advanced option so it's kinda hidden away.

Go "Settings->Compiler->["Other settings" tab]" and click "Advanced options". In the dialog that pops up, go to the "Others" tab and look near the bottom:

• Use flat objects, and
• Use full paths for source files (GDB workaround)

The first one "flattens" the object file (e.g. "src/main.o" becomes "src_main.o") and the second one uses full paths for compiling so GDB can find the source files no matter what...

 :oops: How did I miss that? Thanks....

[MortenMacFly]

• Use flat objects, and
• Use full paths for source files (GDB workaround)

Something new for me, too... Nice to know we have such feature... Hehe... erm... :oops: :roll: