Customizing Project Setup Wizards

[imallett]

Hi,

I'm trying Code::Blocks, coming from a VS 2010/2013 background. My (100% C++) code is cross-platform between Linux and Windows, and between x86 and x86-64.
I would like to customize the project setup wizards so that they:

• Setup four build targets (x86 debug, x86 release, x86-64 debug, x86-64 release), with correct associated compiler flags
• A batch build (to build all of the above) virtual targets
• Use certain default compiler warnings. I use extremely strict compiler warnings when compiling all my projects. I couldn't find a way to set these flags globally--for all projects.
• Don't add default source files

Additionally:
I intend on multiple workspaces. Most of the workspaces will comprise a project for the library plus several more for its tests.

Many of these custom libraries depend on lower-level custom libraries. Since there are many libraries, each with four targets/output paths, it is impractical to add include/lib directories to all the projects that use that library. Visual Studio has a nice feature (property pages) that allows each dependent-project to include a single common configuration file with all the information for all of the configurations for a given dependency-project. Does Code::Blocks have something similar?
Note: the only information I could really find about doing these seemed to suggest that I would need to script some plugins. Before I jump down that rabbithole, I'd like to know if I have other options.
Thanks,
Ian

[MortenMacFly]

Many of these custom libraries depend on lower-level custom libraries. Since there are many libraries, each with four targets/output paths, it is impractical to add include/lib directories to all the projects that use that library.

You can use the concept of targets here: A project can share the project settings with targets and targets can extend or even override the project settings.

Check the Code::Blocks main project file for how its done. You can also consult the manual, its explained there with images, too.

[stahta01]

Look at patching the wiz.cpp in src\plugins\scriptedwizard; and, would likely need to patch all or some the wizard script files.

Obvious Wizard C functions that need patched/renamed/split
Wiz::Launch
Wiz::RegisterWizard
Wiz::RunProjectWizard
// remember to also do the Debug versions
Wiz::GetReleaseName
Wiz::GetWantRelease
Wiz::GetReleaseOutputDir
Wiz::GetReleaseObjectOutputDir
Wiz::SetReleaseTargetDefaults

I am thinking also most functions using m_pWizBuildTargetPanel variable would need patched.

Things I a not sure on are
      Wiz::RunTargetWizard
      Wiz::GetTargetName
      Wiz::GetTargetOutputDir
      Wiz::GetTargetObjectOutputDir


Obvious Wizard script functions the need patched/renamed/split
      SetupTarget  (I would suggest add a SetupTarget64 and leaving the SetupTarget  the same name reason there are 16 and 32 bit only          compiler supported by Code::Block)


I just read the wiz.cpp code less than a day ago; thought I would point you in the likely right direction.
(I am working on updating the CB Plugin Wizard; right now.)

Tim S.

[imallett]

Many of these custom libraries depend on lower-level custom libraries. Since there are many libraries, each with four targets/output paths, it is impractical to add include/lib directories to all the projects that use that library.

You can use the concept of targets here: A project can share the project settings with targets and targets can extend or even override the project settings.

I think perhaps you misunderstand. Example:

•     Workspace A
  • Project I (library)
    • 1. Target debug x86
    • 2. Target release x86
    • 3. Target debug x86-64
    • 4. Target release x86-64
  • Project II (executable)
    • 1. Target debug x86 depends on A.I.1
    • 2. Target release x86 depends on A.I.2
    • 3. Target debug x86-64 depends on A.I.3
    • 4. Target release x86-64 depends on A.I.4
•     Workspace B
  • Project I (library)
    • 1. Target debug x86 depends on A.I.1
    • 2. Target release x86 depends on A.I.2
    • 3. Target debug x86-64 depends on A.I.3
    • 4. Target release x86-64 depends on A.I.4
  • Project II (executable)
    • 1. Target debug x86 depends on A.I.1, B.I.1
    • 2. Target release x86 depends on A.I.2, B.I.2
    • 3. Target debug x86-64 depends on A.I.3, B.I.3
    • 4. Target release x86-64 depends on A.I.4, B.I.4

In my setup, there will be lots of workspaces like B--those whose projects depend on other workspaces' projects.  Obviously, adding the include/lib paths for each target for each project for each workspace is impractical.  Notice that just for this small example, Project B.I depends on four different targets while Project B.II depends on eight.

Look at patching the wiz.cpp in src\plugins\scriptedwizard; and, would likely need to patch all or some the wizard script files.

. . .

I had a look, but none of it really looked amendable to a quick hack.  I'm really only just trying out Code::Blocks; forking the project and making changes is kindof out of scope for me.

Maybe I can write some small scripts to just generate the project files directly.  The format looks pretty simple, and I can just add/delete project files from that.

[stahta01]

Then create a project template and use it.

Tim S.

[imallett]

Then create a project template and use it.

Excellent; this was exactly what I needed to set up the build configurations/targets the way I needed. Suffers from the problem of not having centralized settings for all workspaces, but I think it's acceptable for now. Thanks.

Still don't know how to do inter-workspace dependencies, though. The only thing I could find were inter-project dependencies. I can understand if the build status of other workspaces cannot be managed, but I do need a way to add other workspaces' projects' include/lib paths--without adding them one-by-one for each workspace's project's target.

[stahta01]

I hate the CB Project dependency (workspace based); you might like it.
This is under "Project" -> "Properties"
Tab "Project Settings"
Button "Project Dependency"

I  like the external dependency much better.

This is under "Project" -> "Properties"
Tab "Build Target"
Button "Dependencies"

Tim S.

[imallett]

Excellent; this was exactly what I needed to set up the build configurations/targets the way I needed. Suffers from the problem of not having centralized settings for all workspaces, but I think it's acceptable for now.

For some reason, for static libraries, it seems to add extra "lib" string(s) onto some of the targets' output filenames (so e.g. "libliblibmyproject.a"). This isn't in the template; maybe it happens during renaming.

I  like the external dependency much better.

This is under "Project" -> "Properties"
Tab "Build Target"
Button "Dependencies"

What do I add here? I guess these correspond to this and this.

I hate the CB Project dependency (workspace based); you might like it.

I guess this is useful for forcing re-compile/re-link for dependent projects within one workspace? If so, I will use this for that purpose.
However, like I said, at this point I'm more concerned with adding correct includes and library paths. Under "Settings->Compiler->[Tab] Search Directories", I can change global compiler include and library paths. However, this isn't really appropriate for adding paths for user libraries. Also, there isn't a way to add a library to link against for each target (not that I'd necessarily want to link against every global library).

In the similar "Project build options" page, there is a similar per-project search directories, that I could make work, but it seems to me that doing this for each project doesn't scale--nor is it cross-platform without adding more targets for each platform.

[stahta01]

NOTE: Your remarks about external dependency made no sense to me; this may mean they are wrong.

Sounds like you want a custom script to do what you want.
I am NOT really sure how to do those.
Also, you might wish to look at the nightly plugin "ProjectOptionsManipulator" it might be able to do what you want.

Another option is use premake to build "standard" CB Projects or cmake to build "custom makefile" CB Projects.
Note: premake and cmake are 3rd party project build tools.

But, I still do NOT see the need for multiple workspace dependency; this might mean you do NOT understand CB  workspaces or I do NOT understand what you are needing.

Tim S.

[cacb]

However, like I said, at this point I'm more concerned with adding correct includes and library paths. Under "Settings->Compiler->[Tab] Search Directories", I can change global compiler include and library paths. However, this isn't really appropriate for adding paths for user libraries. Also, there isn't a way to add a library to link against for each target (not that I'd necessarily want to link against every global library).

Hi, I like your approach and stated goals (even though my own may be slighty different).

For managing paths, I presume you are aware of the global variables feature in Code::Blocks? In my opinion, this is one of the strongest features of the IDE, as it separates the project setup from the physical include and library paths. See Settings -> Global variables.... For example define a variable BOOST and then refer to it in project files using $(#BOOST.include) and $(#BOOST.lib). This also helps make your projects cross platform (mine are cross platform across Windows & Linux).

Notice also that compiler and linker settings can be defined on both project level and target level. As you have seen, you may define inter-project dependences within a workspace. When you have multiple build targets in multiple projects, my experience is (someone correct me if I am wrong) that it really means dependencies between build targets (using the same target name) in different projects. So your scenario involving Project I (library) and Project II (executable) seems satisfied.

I am a bit more fuzzy on external (inter-workspace) dependencies, so I shall not say to much. In my personal opinion, mentioning a library name in the list of libraries to link is a declaration that the current build target depends on that library, regardless of how or where the library is created (same C::B workspace, other  C::B workspace, from 3rd party not using C::B). It may be that in reality things are not quite as transparent as this, but I do have several workspaces with projects referring to libraries not in the current workspace, and it seems to work fine.

Each of my projects includes a post-build step exporting include files, libraries and executables to a location different from the project itself. Dependent projects refer to include files and library files in that location via a global variable (or environment variable). I've made my own utility for this purpose as I think it simplifies managing multi-workspace development. I've also created my own utility for generating C::B project files using this scheme, and it seems to work ok (I'd be willing to share these utilities if anyone wants to include them in C::B, but I guess some work is to be expected).

[imallett]

NOTE: Your remarks about external dependency made no sense to me; this may mean they are wrong.
...
But, I still do NOT see the need for multiple workspace dependency; this might mean you do NOT understand CB  workspaces or I do NOT understand what you are needing.

I have used Code::Blocks a little more.  I now think they are just an arbitrary collection of projects, rather than something overarching (as a "solution" is in MSVC).  Correct?

Sounds like you want a custom script to do what you want.
I am NOT really sure how to do those.

Actually, in the time since my last post, I wrote a Python build system.  It essentially generates the project file in the manner I require, adding include directories, library directories, build configurations, compiler options, and so on.  Really crufty, but super effective: my entire codebase compiles correctly now.

Also, you might wish to look at the nightly plugin "ProjectOptionsManipulator" it might be able to do what you want.

Another option is use premake to build "standard" CB Projects or cmake to build "custom makefile" CB Projects.
Note: premake and cmake are 3rd party project build tools.

I have used cmake, and it's . . . annoying to use.  I haven't even tried generating project files from it.  I haven't heretofore heard of premake, although it looks nice (better than cmake anyway).

Hi, I like your approach and stated goals (even though my own may be slighty different).

For managing paths, I presume you are aware of the global variables feature in Code::Blocks? In my opinion, this is one of the strongest features of the IDE, as it separates the project setup from the physical include and library paths. See Settings -> Global variables.... For example define a variable BOOST and then refer to it in project files using $(#BOOST.include) and $(#BOOST.lib). This also helps make your projects cross platform (mine are cross platform across Windows & Linux).

I thought I did, and then I reread your post.  I will definitely have to do this.  I was previously considering making separate targets for each platform, which is obviously terrible.

Notice also that compiler and linker settings can be defined on both project level and target level. As you have seen, you may define inter-project dependences within a workspace. When you have multiple build targets in multiple projects, my experience is (someone correct me if I am wrong) that it really means dependencies between build targets (using the same target name) in different projects. So your scenario involving Project I (library) and Project II (executable) seems satisfied.

I can't quite parse this.  Most of the options are in fact specified on a project level, but I do have some things on a target level.  The main thing is coming up with a clean way to make targets of one project depend on the same targets of another.  As above, the cleanest way I found to do this is to resolve all the dependencies in my Python script and then just write the project file from nothing accordingly.

I'll probably just be using the Python script for now.  It does (or very shortly will do) what I need exactly, even if it isn't pretty.  Maybe in the future I'll look into premake.

Thanks,

[stahta01]

NOTE: Your remarks about external dependency made no sense to me; this may mean they are wrong.
...
But, I still do NOT see the need for multiple workspace dependency; this might mean you do NOT understand CB  workspaces or I do NOT understand what you are needing.

I have used Code::Blocks a little more.  I now think they are just an arbitrary collection of projects, rather than something overarching (as a "solution" is in MSVC).  Correct?

Correct.

Edit: I do think you need to try using external dependency in your target to target dependency.
Edit2: Look at the macro names for the target; will make script easier to write.
EDIT2b: http://wiki.codeblocks.org/index.php?title=Variable_expansion $(TARGET_NAME)

Tim S.