Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: heilpern on November 09, 2005, 06:40:26 pm

Title: Multiple drive problem
Post by: heilpern on November 09, 2005, 06:40:26 pm
I am porting an existing project from the Microsoft Visual Studio environment to CodeBlocks/MinGW, and having a problem getting the build.

My project uses files from two mapped drives, call them X: and Y:, and the project itself is on the X: drive. My sources that live on the X: drive compile fine and the .o's are placed in the .objs/relative/path location. My files that live on the Y: drive can't compile because the location CodeBlocks wants to place the .o's is invalid -- it wants to put them in .objs/Y:/relative/path, and the colon in there is a problem.

Short of moving files around (which would be a problem within my organization) any suggestions? I'm thinking one option is to export a Makefile and edit that by hand, but I'd prefer not to just yet. I've noticed that if I choose properties of a source file, the advanced tab has a line edit for the object, but this box isn't editable. In my example, it appears as Y:/relative/path/file.o, so clearly it gets the .objs/ portion prepended prior to use... if I could edit the value shown (perhaps there's a setting to enable that?) then I should be able to compile.

I'm using 1.0rc2 of CodeBlocks.

Thanks much...
Title: Re: Multiple drive problem
Post by: sethjackson on November 09, 2005, 07:18:01 pm
You could make two targets one for the X: drive and one for Y:........
Title: Re: Multiple drive problem
Post by: MortenMacFly on November 09, 2005, 10:16:19 pm
My project uses files from two mapped drives, call them X: and Y:, [...]
This doesn't help you for now but:
http://sourceforge.net/tracker/index.php?func=detail&aid=1345727&group_id=126998&atid=707416
seems to describe exactly the problem you explain here.

Morten.
Title: Re: Multiple drive problem
Post by: killerbot on November 10, 2005, 04:45:00 am
Or an option to turn of the relative path's in the objs directory, so it just works again with a flat level of objects. This relative path's might be a problem for certain linkers, I am not sure yet, but it might be problematic for the ti linker (I still have to continue my activation of the ti compiler/linker inside CB).