Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: grreg on May 10, 2006, 03:46:01 am

Title: Conceptual help with "workspace"
Post by: grreg on May 10, 2006, 03:46:01 am

Hi, I'm just getting started with some programming tutorials and so far I'm thrilled with how easy it was to install code::blocks and start writing beginner code. I understand source files and object files and it seems clear that "projects" are collections of related source and object files, but I'm confused by this "workspace" idea. Can someone give a conceptual overview of where it fits into the organizing structure I'm looking at? I've lost some of the my first few attempts because it isn't clear to me how to properly save the stuff I've done in a way that will keep it organized. I'd really appreciate any help.
-Greg

Title: Re: Conceptual help with "workspace"
Post by: Game_Ender on May 10, 2006, 04:02:02 am

There are three main concepts here, Targets, Project and Workspaces.  Every project has multiple targets, every workspace has multiple projects.  Each target represents a single output, usually an executable or library file of some sort.  Most things you do as a beginner will involve just one project.  That one project my have a targets for a support library, main program and test suite.  These targets will each be dependent on the source files of your project and will be rebuilt when any of there dependent files change.

Now that you kind of get what project you can understand workspaces better.  They are just a collection of the projects you are currently working on.  In that workspace you can only have on active project at a time.  There is a default workspace that codeblocks will maintain, but you can create you own if you are working on a very large system that has many subprojects.  Ogre for example has workspace containing projects for its main library, platform support libraries, demos and tools.  You can tell codeblocks to build the entire workspace.  You can also tell codeblocks that certain projects are dependent on other projects.  So if you were working in our Ogre workspace and update the OgreMain project, all of the demo projects would be rebuilt because they were set to be dependent on the OgreMain project.

Title: Re: Conceptual help with "workspace"
Post by: grreg on May 10, 2006, 04:55:57 am

Hi Game_Ender,
thanks for the overview, I think I understand the idea. I seem to be having trouble with the execution. I created my first project using the "file/new project" menu item. It brings up a dialog for choosing what I believe is the target?(console application, dynamic link libary, ogre apllication, etc...) since I'm starting with the simple "hello world" thing I chose console application. Now I have a project called "console application" (actually I have a few projects called that because I can't figure out how to give them different names) which contains my "hello world" source file which is called main. So when the next chapter of my book wants me to write a new program, I should create a new project within the same workspace, right? They will all be console applications at this stage and I may as well keep all my attempts in one workspace. I've tried using "save project as..." to make a copy of what I was doing so I could modify it while retaining my previous work. But the project file that results won't open. I've looked for documentation so I wouldn't have to ask so many questions, but either I failed to find it or there isn't much.
-Greg

Title: Re: Conceptual help with "workspace"
Post by: Game_Ender on May 10, 2006, 06:48:26 pm

Those choices you see are project templates/wizards.  They help you get started by adjusting the starting settings of the projects they generate.  This makes it easier include the proper libraries, have proper output file type, etc.  So in short, they just configure the project, they aren't targets.

The "Save Project As..." and "Save Workspace As..." options don't create copy the entire contents of the project, they only copy the project file it self, or the workspace file itself.  It is important to remember that CB starts up with its default workspace so if you want a special to create it (as you have already figured out).  It is also important to note that a workspace is just an xml file that stores the relative file system path to each of its projects and some other information. Here is how I would layout my work:

Code

My_Files/
    My_Work_1/
        work.workspace
        Console_Proj_1/
        Console_Proj_2/
    My_Work_2/
        work.workspace 
        Console_Proj_1/
        Console_Proj_2/
        New_Console_Proj/

So the "My_Work_1" directory is manually created by you to keep your work in.  Then you tell CB to create you new projects in the "My_Files/My_Work_1" folder.  After you have created more projects and want to save you workspace just use "Save Workspace As..." and save the workspace in the "My_Work_1" folder.  Now if you want to keep this set group of work and make some major changes you must manually copy the "My_Work_1" folder.  After this if you want to work in your first workspace just open up "My_Work_1/work.workspace" or "My_Work_2/work.workspace" for you new one. 

Title: Re: Conceptual help with "workspace"
Post by: Game_Ender on May 10, 2006, 06:50:30 pm

You seem a little new to development, what you are trying to do is better accomplished with a Source Control System.  Once you feel more experience with how compilers, linking and Code::Blocks works see this informative howto (http://www.ericsink.com/scm/index.html) and once you get that, check out information about SVN (http://svnbook.red-bean.com/en/1.2/index.html) the source control system CB developers use.

Source Control in a nut shell:  It keeps track of changes to your files and folders in a central repository.  This lets you go back to any version of those files or compare you current versions.

Title: Re: Conceptual help with "workspace"
Post by: grreg on May 10, 2006, 07:26:19 pm

"Those choices you see are project templates/wizards.  They help you get started by adjusting the starting settings of the projects they generate.  This makes it easier include the proper libraries, have proper output file type, etc.  So in short, they just configure the project, they aren't targets."

I see.

Aha!

"The "Save Project As..." and "Save Workspace As..." options don't create copy the entire contents of the project, they only copy the project file it self, or the workspace file itself."

This is the missing piece of the puzzle and explains the behaviour that was confusing me. Now I think I see what's going on. With that in mind, your explanation of how you would lay out your work makes perfect sense.

"You seem a little new to development,"

That would be an understatement!

"...what you are trying to do is better accomplished with a Source Control System."

I think I gave that impression, but I'm not trying to save multiple versions. I was just trying to shortcut by doing what I might do if I were word-processing, namely, use save as to create a copy of what I'm doing under a new name and then erase the text and start the new thing I want to write. But thank you for the links to SVN and the how-to, I can see right away how necessary and helpful source control tools would be. I will read through those today.

Thanks for your time and help!
-Greg

Title: Re: Conceptual help with "workspace"
Post by: mejohnsn on May 28, 2006, 09:51:05 am

Quote from: grreg on May 10, 2006, 04:55:57 am

since I'm starting with the simple "hello world" thing I chose console application. Now I have a project called "console application" (actually I have a few projects called that because I can't figure out how to give them different names) which contains my "hello world" source file which is called main.

Two suggestions:

1 - When you create a project using the File:New Project or Project:New Project wizards, make a separate directory for each project. That way, when it creates 'main.cpp', it will not clobber some other 'main.cpp' (among other benefits)

2 - Since 'console application' is such an un-unique name, you should rename the project (as the title appears in C::B's Projects tab) by selecting the project, right-clicking on it, and go to Properties:Project:Title and enter your own descriptive name for the project. You might, for example, make it match the directory name of 1).

Of course Game_Ender's suggestions are also good, but since you are a beginner, you might want to get your feet wet with my two suggestions above before you tackle his rather more involved approach.