Directories for object files

[hd]

Hi,

Seeing .deps directories for project tree, I thought why not same solution
for object files ? Ex. if project has two configuration: release and debug,
then create .release and .debug directories, and use them.


ps. Thanks for CodeBlocks. I'm using it daily.

--
Hakki Dogusan

[troels]

Hi Yiannis,

I agree with the following post, except to me this is crucial. Controlling where output files goes is much needed, having .c and .o files is the same folder is messy. Eclipse/CDT apparantly cannot do this. MinGW Developer Studio do do this. MinGW Developer Studio is (was) great, with this little extra feature plus the Linux port CodeBlocks becomes greater still, bound to have a huge impact! This is a very very important project you've started, good luck. I really need this IDE!

/Troels

PS:cpp/wx is much better than Java/Eclipse/CDT, way beyond

[mandrav]

I am trying to add it in before the next version, i.e. any day now

[troels]

Hi,

>I am trying to add it in
Great! Thanks.

>>having .c and .o files is the same folder is messy
I don't understand why the *nix people put up with this.

>MinGW GNU GCC...the same plugin can use the free(!) Microsoft
>Visual C++ Toolkit 2003 just as easily.
Ultra-cool! Openness - flexibility - freedom of choice!

Greetings,
Troels, Denmark

[hd]

Hi,


(subject could be "You can't make everybody happy!" ;-))

(using cvs version of CodeBlocks)


This .objs directory solution is better than none...

- But if you have to use a source/header file in a directory which you don't
have write rights ?

- It does not solve common debug/release configuration problem
  -requires rebuild every time ?-

Thanks for listening, and hard work!

--
Regards,
Hakki Dogusan

[mandrav]

Hi,

(using cvs version of CodeBlocks)

This .objs directory solution is better than none...

Yes, think of it as the first step...

- But if you have to use a source/header file in a directory which you don't
have write rights ?

You 've got a valid point. Expect a fix (i.e. configuration option) soon.

- It does not solve common debug/release configuration problem

This "common debug/release configuration" is actually common between MSVC users. I never had the need for that. I always work with debugging flags on and when the project is done, I compile it as "release", i.e. stripped of debugging info and optimized.
Anyway, I 'll see what can be done about an "object-output" option *per-target*...

 -requires rebuild every time ?-

Ofcourse no! How did you reach this conclusion?

Greetings,
Yiannis.

[troels]

I 'll see what can be done about an "object-output" option *per-target*...

It's in Beta5! Very well done, it's a killer feature. This is an amazing program!
/Troels

[hd]

(Note: It is not me who started this again ;-))

Would you mind to look following makefile fragments please:

- This one is generated by ide

..\\..\\..\\_lib\\.deps\\LocaleUtils.d: ..\\..\\..\\_lib\\LocaleUtils.cpp
   @echo Calculating dependencies for "..\..\..\_lib\LocaleUtils.cpp"...
   -@if not exist ".\..\..\..\_lib\.deps\." mkdir ".\..\..\..\_lib\.deps"
   @$(CPP) -MM $(gc_release_CFLAGS) -MF ..\\..\\..\\_lib\\.deps\\LocaleUtils.d -MT ..\\..\\..\\_lib\\.orgc\\LocaleUtils.o $(gc_release_INCS) ..\\..\\..\\_lib\\LocaleUtils.cpp

..\\..\\..\\_lib\\.orgc\\LocaleUtils.o: ..\\..\\..\\_lib\\.deps\\LocaleUtils.d
   @echo Compiling "..\..\..\_lib\LocaleUtils.cpp"...
   -@if not exist ".\..\..\..\_lib\.orgc\." mkdir ".\..\..\..\_lib\.orgc"
   @$(CPP) $(gc_release_CFLAGS) $(gc_release_INCS) -c ..\\..\\..\\_lib\\LocaleUtils.cpp -o ..\\..\\..\\_lib\\.orgc\\LocaleUtils.o

..\\..\\..\\_lib\\.deps\\Lua_Interpreter.d: ..\\..\\..\\_lib\\Lua_Interpreter.cpp
   @echo Calculating dependencies for "..\..\..\_lib\Lua_Interpreter.cpp"...
   -@if not exist ".\..\..\..\_lib\.deps\." mkdir ".\..\..\..\_lib\.deps"
   @$(CPP) -MM $(gc_release_CFLAGS) -MF ..\\..\\..\\_lib\\.deps\\Lua_Interpreter.d -MT ..\\..\\..\\_lib\\.orgc\\Lua_Interpreter.o $(gc_release_INCS) ..\\..\\..\\_lib\\Lua_Interpreter.cpp

..\\..\\..\\_lib\\.orgc\\Lua_Interpreter.o: ..\\..\\..\\_lib\\.deps\\Lua_Interpreter.d
   @echo Compiling "..\..\..\_lib\Lua_Interpreter.cpp"...
   -@if not exist ".\..\..\..\_lib\.orgc\." mkdir ".\..\..\..\_lib\.orgc"
   @$(CPP) $(gc_release_CFLAGS) $(gc_release_INCS) -c ..\\..\\..\\_lib\\Lua_Interpreter.cpp -o ..\\..\\..\\_lib\\.orgc\\Lua_Interpreter.o




- This one is hand edited -again generated by ide-

.deps\\_lib\\LocaleUtils.d: ..\\..\\..\\_lib\\LocaleUtils.cpp
   @echo Calculating dependencies for "..\..\_lib\LocaleUtils.cpp"...
   -@if not exist ".deps\_lib\." mkdir ".\.deps\_lib"
   @$(CPP) -MM $(gc_release_CFLAGS) -MF .deps\\_lib\\LocaleUtils.d -MT .orgc\\_lib\\LocaleUtils.o $(gc_release_INCS) ..\\..\\..\\_lib\\LocaleUtils.cpp

.orgc\\_lib\\LocaleUtils.o: .deps\\_lib\\LocaleUtils.d
   @echo Compiling "..\..\_lib\LocaleUtils.cpp"...
   -@if not exist ".\.orgc\_lib\." mkdir ".\.orgc\_lib"
   @$(CPP) $(gc_release_CFLAGS) $(gc_release_INCS) -c ..\\..\\..\\_lib\\LocaleUtils.cpp -o .orgc\\_lib\\LocaleUtils.o

.deps\\_lib\\Lua_Interpreter.d: ..\\..\\..\\_lib\\Lua_Interpreter.cpp
   @echo Calculating dependencies for "..\..\_lib\Lua_Interpreter.cpp"...
   -@if not exist ".\.deps\_lib\." mkdir ".\.deps\_lib"
   @$(CPP) -MM $(gc_release_CFLAGS) -MF .deps\\_lib\\Lua_Interpreter.d -MT .orgc\\_lib\\Lua_Interpreter.o $(gc_release_INCS) ..\\..\\..\\_lib\\Lua_Interpreter.cpp

.orgc\\_lib\\Lua_Interpreter.o: .deps\\_lib\\Lua_Interpreter.d
   @echo Compiling "..\..\_lib\Lua_Interpreter.cpp"...
   -@if not exist ".\.orgc\_lib\." mkdir ".\.orgc\_lib"
   @$(CPP) $(gc_release_CFLAGS) $(gc_release_INCS) -c ..\\..\\..\\_lib\\Lua_Interpreter.cpp -o .orgc\\_lib\\Lua_Interpreter.o



IDE is confused nested directories, IMO.

Since both are working/compiling, maybe it is not that important...

--
Regards,
Hakki Dogusan

[mandrav]

Hi Hakki

which CB version is exporting these two makefiles?
Up to (and including) beta5, the deps and objects dirs are created in the same dir with the file that is being compiled. This means that if you have a multi-dir source tree, in every dir with compilable files you will find .objs and .deps (assuming the default names) dir in each of these directories

The CVS version has changed this and creates .objs and .deps dir only once (where you configure it) and under there creates a directory tree same as the one your source files reside (I think it's the exact same behaviour as MSVC - wouldn't know 'cause I 've never used it but that's what I 'm told )

I hope I cleared this a bit,
Yiannis.

[hd]

Hi,

(cb version is "bleeding edge" )

I frist export makefile, then hand edit it.


If you design your project directories as cb, than there is no problem. I think that is the reason you
don't know about the problem?

But my project tree is as following:


/a_C/_lib                      (common source files are here)
/a_C/adret                    (project source files are here)
/a_C/build/cb                (cb project file is here)

/a_C/build/cb/.deps       (for dependency files)
/a_C/build/cb/.orgc        (for gcc release object files)
/a_C/build/cb/.odgc       (for gcc debug object files)
/a_C/build/cb/.ordm      (for dmc release object files)
/a_C/build/cb/.oddm      (for dmc debug object files)
/a_C/build/cb/.orvc        (for vc release object files)
/a_C/build/cb/.odvc       (for vc debug object files)
/a_C/build/cb/.orbc        (for bcc release object files)
/a_C/build/cb/.odbc       (for bcc debug object files)

Yes, I'm a dreamer


IMHO, if cb can remove "relativity" from object files than problem will solved.

ie:

instead of : ..\\..\\..\\_lib\\.deps\\LocaleUtils.d: ..\\..\\..\\_lib\\LocaleUtils.cpp

remove ..\\..\\..\\  and use this: .deps\\_lib\\LocaleUtils.d: ..\\..\\..\\_lib\\LocaleUtils.cpp


Hope I could tell my thinkings..

--
Regards,
Hakki Dogusan

[mandrav]

If you design your project directories as cb, than there is no problem. I think that is the reason you
don't know about the problem?

I build other project too

Take, for example, the rendering engine OGRE. I 've built this using CB. Here is a rough directory structure:

Code

ogrenew <-- top dir
  Build <-- I created this dir to put all build files in
  OgreMain
    include
    src <-- main DLL source dir
    scripts <-- project files for VC. This is where OgreMain.cbp resides ;)
  ... <-- more directories with other DLLs source files

In the CB project, I have two targets: Debug and Release. These are the build dirs defined for those targets:

Code

Debug objects: ..\..\Build\Debug
Debug deps: ..\..\Build\.deps
Release objects: ..\..\Build\Release
Release deps: ..\..\Build\.deps

Let me note here that all relative paths in CB are relative to the project file (.cbp)

When I build OgreMain.cbp (the Release target), the Build directory has the following structure:

Code

ogrenew <-- top dir
  Build <-- I created this dir to put all build files in
    Release <-- this is the main build dir for the Release target
      OgreMain
        src <-- this dir is filled with object files
  OgreMain
    include
    src <-- main DLL source dir
    scripts <-- project files for VC. This is where OgreMain.cbp resides ;)
  ... <-- more directories with other DLLs source files

Do you see something wrong with the above?
I don't

Something just came to my mind: I always use the "direct-mode" for building, i.e. no GNU make. Maybe there is a bug there? I 'll have to check.
Have you tried building your project using "direct-mode"? Are your results the same?

Yiannis.

[hd]

Hi again!

-

I build other project too

You should not! Drop all projects but cb now!

- I'm using "direct-mode" also
- My configuration is gcc-3.4.2, wx2.5.4, xp
- I recreated the project simulating your structure, but result is not as yours !?
- Interesting but I can see "normal" behaivour when compiling cb itself

There should be something stupid..maybe it's me


For your reference I'm pasting compiler's linking release target log:

mingw32-g++.exe   -L"C:\\MinGW\\lib"  -L"..\\..\\..\\..\\wx25\\lib\\gcc_lib" -L"..\\..\\..\\..\\lua\\lib" -o "adret-gc_release.exe" ".orgc\\..\\..\\..\\_lib\\LocaleUtils.o" ".orgc\\..\\..\\..\\_lib\\Lua_I18N.o" ".orgc\\..\\..\\..\\_lib\\Lua_Interpreter.o" ".orgc\\..\\..\\..\\_lib\\Lua_wxDialog.o" ".orgc\\..\\..\\..\\_lib\\Lua_wxSQLite.o" ".orgc\\..\\..\\..\\_lib\\Reporter.o" ".orgc\\..\\..\\..\\_lib\\dbadaptr.o" ".orgc\\..\\..\\..\\_lib\\dbfind.o" ".orgc\\..\\..\\..\\_lib\\toggle.o" ".orgc\\..\\..\\..\\_lib\\wxsqlite.o" ".orgc\\..\\..\\AboutDialog.o" ".orgc\\..\\..\\AddressEdit.o" ".orgc\\..\\..\\AdretApp.o" ".orgc\\..\\..\\AdretWin.o" ".orgc\\..\\..\\LabelSetup.o" ".orgc\\..\\..\\dbAddress.o"  ".orgc\\..\\..\\resources.res"     -Wl,--subsystem,windows -mwindows    -llua -llualib -lwxmsw25 -lwxmsw25_stc -lwxexpat -lwxjpeg -lwxpng -lwxregex -lwxtiff -lwxzlib -lrpcrt4 -lwsock32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lctl3d32 -ladvapi32 -lole32 -loleaut32 -luuid -mwindows


Sorry for noise...

--
Regards,
Hakki Dogusan

[chikigai]

Adding to the subject, I'd like to explain an issue I am experiencing with CodeBlocks V1.0.
Here is a layout of a simple project I am working on:

ASL
├─Project          <--- Project & Makefile files reside
│  └─GCC          <--- DLL output resides
│      ├─.deps     <--- Dependency files reside
│      └─.objs      <--- Object files resides
└─Work             <--- Source/header files reside


*** Using Direct Mode ***
When I originally created the project and compiled, the object files were outputted to "ASL/Project/GCC/.objs/Work" which was automatically created by CodeBlocks.
This is despite the fact I specified the output directory to "ASL/Project/GCC/.objs" in the target options.

After a quick look around, I found that the 'Advanced' tab in the properties of each source file contained "Work/<src_name>.o".
I deleted the "Work/" portion of each source file property and this resulted in the object files outputted to the correct directory "ASL/Project/GCC/.objs".

However, when I add/remove a source file from the project, CodeBlocks changes the option of each source file back to "Work/<src_name>.o".

Am I doing something wrong here?


*** Using a Custom Makefile ***
When compiling a specific Build Target, the target name is passed to Make.
This is fine.
However, when compiling a specific Source File, "../Work.objs/<src_name>.c" is passed to Make.

I have looked around to spot why CodeBlocks is inserting the ".objs" in the path but have had no success.

[Profic]

All is right here. (Direct mode)
Suppose you fave two file with similiar name but in different directories - objects for them will overwrite each other. This thing annoys me in Dev-C++.

Moreover is it really important were object files are reside? C::B manage paths properly and generate dll/exe in proper directory. Isn't is enough?