User forums > Using Code::Blocks

Customizing Project Setup Wizards

(1/3) > >>

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 filesAdditionally:
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:

--- Quote from: imallett on February 14, 2014, 06:24:02 am ---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.

--- End quote ---
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:

--- Quote from: MortenMacFly on February 14, 2014, 09:04:14 am ---
--- Quote from: imallett on February 14, 2014, 06:24:02 am ---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.
--- End quote ---
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.
--- End quote ---
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.4In 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.


--- Quote from: stahta01 on February 14, 2014, 11:43:32 am ---Look at patching the wiz.cpp in src\plugins\scriptedwizard; and, would likely need to patch all or some the wizard script files.

. . .
--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page

Go to full version