Difference between revisions of "Compile Code::Blocks plugins based on a nightly"
MortenMacFly (talk | contribs) |
(new svn) |
||
(12 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | ''' | + | First, a general note: This article applies to '''Windows/MinGW compiler only''' for the moment, feel free to extend the article, if you see a similar possibility on other platforms. |
So, you don't want to compile wxWidgets or Code::Blocks core but still want to be able to modify a certain plugin (for example) and use the modified plugin in your favourite nightly? Its possible. Here is what you need: | So, you don't want to compile wxWidgets or Code::Blocks core but still want to be able to modify a certain plugin (for example) and use the modified plugin in your favourite nightly? Its possible. Here is what you need: | ||
− | * The wxWidgets ''sources'' (!) - no need to compile them, just download from [http://www.wxwidgets.org/downloads here]. | + | * The wxWidgets ''sources'' (!) - no need to compile them, just download from [http://www.wxwidgets.org/downloads here] ''but exactly the version, the nightly is built on''. |
* A nightly of your choice, download from [/index.php/board,20.0.html here]. | * A nightly of your choice, download from [/index.php/board,20.0.html here]. | ||
− | * The Code::Blocks sources in the revision the nightly is based on from [ | + | * The MinGW/GCC compiler used to build the nightly - as written in the nightly section and usually available from here [http://tdm-gcc.tdragon.net here]. Note that the version (i.e. v4.5.2) ''and'' flavour (i.e. sjlj or dwarf) ''must'' match. Usually this information is available [/index.php/topic,3299.msg26011.html here]. |
+ | * The Code::Blocks sources in the revision the nightly is based on from [https://sourceforge.net/p/codeblocks/code/ here]. You usually get these, if you issue a: | ||
svn checkout svn://somepath@1234 working-directory | svn checkout svn://somepath@1234 working-directory | ||
− | For example, to checkout trunk at revision 8150 into the folder you are currently in, issue: | + | ...on the command line (having the [https://subversion.apache.org Subversion tools] installed properly). For example, to checkout trunk at revision 8150 into the folder you are currently in, issue: |
− | svn checkout svn://svn. | + | svn checkout svn://svn.code.sf.net/p/codeblocks/code/trunk@8150 working-directory |
− | * The sources of the plugin / component you want to change should be included in this checkout, you can (however | + | * The sources of the plugin / component you want to change should be included in this checkout, you can (however) update the specific folder to SVN HEAD, if you like. |
− | One note: This surely ''only'' works, if the SDK version is compatible to the plugin. What won't work is, if the plugin makes use of SDK methods not available in the SDK version the nightly is based on. | + | One note: This surely ''only'' works, if the SDK version is compatible to the plugin. What won't work is, if the plugin makes use of SDK methods not available in the SDK version the nightly is based on. Luckily, the SDK is quite stable and existing (stable) plugins rarely change to make use of new SDK methods. |
Now comes the "hard" part: You'll need to adjust the plugin's project file, so it links against the DLL's from the nightly (yes, MinGW can do so!) instead of the import libraries you usually compile. | Now comes the "hard" part: You'll need to adjust the plugin's project file, so it links against the DLL's from the nightly (yes, MinGW can do so!) instead of the import libraries you usually compile. | ||
Line 18: | Line 19: | ||
* Goto the plugin's build options | * Goto the plugin's build options | ||
* Goto linker settings | * Goto linker settings | ||
+ | ** Change the wxmsw28$(WX_SUFFIX) part to become "wxmsw28u_gcc_cb.dll" (the one shipped with the nightly) | ||
+ | ** Change the codeblocks part to become "codeblocks.dll" (the one shipped with the nightly). Note that this change might actually not be needed as MinGW automatically looks for files with the extension *.dll, too... | ||
+ | * Goto the "search directories" settings | ||
+ | ** Change the compilers C::B related include directories (usually setup relative, like ..\..\..\include) to point to the equivalent path's where you checked out the C::B sources | ||
+ | ** Change the compilers wxwidgets related include directories (usually setup like $(#WX.INCLUDE)) to point to the equivalent path's where you extracted the wxWidgets sources, or (in case of global variables like here), just adjust the global compiler variables (GCV's). | ||
+ | ** Do the same with the linker and resource include path's of the plugin (note that i.e. "..\..\..\devel" should not point to the root of your nightly installation folder) | ||
+ | * Note that you might need to do this at project and target level - depending on how the plugin is setup. | ||
+ | * Try to compile and resolve any remaining issues which can only occur, in case you didn't do the above steps carefully. | ||
+ | * Goto the plugin's project options | ||
+ | ** Adjust the objects output folder, if desired | ||
+ | ** Adjust the plugin's output file name and path, if desired | ||
+ | ** Adjust the execution working directory, if desired | ||
− | + | Now you should be able to compile and link the plugin successfully. This will create a plugin version compatible to that nightly. Voilà - feel free to share it with others afterwards. | |
− | |||
− | |||
− | |||
− |
Latest revision as of 14:18, 5 September 2013
First, a general note: This article applies to Windows/MinGW compiler only for the moment, feel free to extend the article, if you see a similar possibility on other platforms.
So, you don't want to compile wxWidgets or Code::Blocks core but still want to be able to modify a certain plugin (for example) and use the modified plugin in your favourite nightly? Its possible. Here is what you need:
- The wxWidgets sources (!) - no need to compile them, just download from here but exactly the version, the nightly is built on.
- A nightly of your choice, download from [/index.php/board,20.0.html here].
- The MinGW/GCC compiler used to build the nightly - as written in the nightly section and usually available from here here. Note that the version (i.e. v4.5.2) and flavour (i.e. sjlj or dwarf) must match. Usually this information is available [/index.php/topic,3299.msg26011.html here].
- The Code::Blocks sources in the revision the nightly is based on from here. You usually get these, if you issue a:
svn checkout svn://somepath@1234 working-directory
...on the command line (having the Subversion tools installed properly). For example, to checkout trunk at revision 8150 into the folder you are currently in, issue:
svn checkout svn://svn.code.sf.net/p/codeblocks/code/trunk@8150 working-directory
- The sources of the plugin / component you want to change should be included in this checkout, you can (however) update the specific folder to SVN HEAD, if you like.
One note: This surely only works, if the SDK version is compatible to the plugin. What won't work is, if the plugin makes use of SDK methods not available in the SDK version the nightly is based on. Luckily, the SDK is quite stable and existing (stable) plugins rarely change to make use of new SDK methods.
Now comes the "hard" part: You'll need to adjust the plugin's project file, so it links against the DLL's from the nightly (yes, MinGW can do so!) instead of the import libraries you usually compile.
Do the following:
- Goto the plugin's build options
- Goto linker settings
- Change the wxmsw28$(WX_SUFFIX) part to become "wxmsw28u_gcc_cb.dll" (the one shipped with the nightly)
- Change the codeblocks part to become "codeblocks.dll" (the one shipped with the nightly). Note that this change might actually not be needed as MinGW automatically looks for files with the extension *.dll, too...
- Goto the "search directories" settings
- Change the compilers C::B related include directories (usually setup relative, like ..\..\..\include) to point to the equivalent path's where you checked out the C::B sources
- Change the compilers wxwidgets related include directories (usually setup like $(#WX.INCLUDE)) to point to the equivalent path's where you extracted the wxWidgets sources, or (in case of global variables like here), just adjust the global compiler variables (GCV's).
- Do the same with the linker and resource include path's of the plugin (note that i.e. "..\..\..\devel" should not point to the root of your nightly installation folder)
- Note that you might need to do this at project and target level - depending on how the plugin is setup.
- Try to compile and resolve any remaining issues which can only occur, in case you didn't do the above steps carefully.
- Goto the plugin's project options
- Adjust the objects output folder, if desired
- Adjust the plugin's output file name and path, if desired
- Adjust the execution working directory, if desired
Now you should be able to compile and link the plugin successfully. This will create a plugin version compatible to that nightly. Voilà - feel free to share it with others afterwards.