Patch to CB Plugin Wizard.

[Jenna]

Why do you think it is bad idea?

1. The CB Projects does not use that method.

The C::B project can not use it, because it creates the necessary (*.pc) files, but the wizard-created plugins have to use an installed codeblocks(-devel).
But to use it in self-compiled C::B's it might be easier and more flexible to use a global variable.

2. That method is broken in the Debian installed CB

Is it broken in our Debian-files or in the packages from the Debian repo ?

3. The only way to get it to work is to self build Code::Blocks using configure/make

It seems to work with my Fedora (nightly-)packages, so it must be broken in some way on Debian.

[stahta01]

Why do you think it is bad idea?

1. The CB Projects does not use that method.

The C::B project can not use it, because it creates the necessary (*.pc) files, but the wizard-created plugins have to use an installed codeblocks(-devel).
But to use it in self-compiled C::B's it might be easier and more flexible to use a global variable.

2. That method is broken in the Debian installed CB

Is it broken in our Debian-files or in the packages from the Debian repo ?

Using the packages from the Debian repo, I believe it does NOT work. No codeblocks.pc files is installed.
I will have to use my dual Linux boot to confirm this; I am building something that will take a few hours before I can reboot.

Tim S.

[Jenna]

Using the packages from the Debian repo, I believe it does NOT work. No codeblocks.pc files is installed.
I will have to use my dual Linux boot to confirm this; I am building something that will take a few hours before I can reboot.

It should be there according to the files-list of codeblocks-dev for testing:

...
/usr/lib/pkgconfig/codeblocks.pc
...

[oBFusCATed]

@stahta01:
If I remember correctly the new project wizard has two targets one uses the pig-config file and the other is meant to be used with a self compiled cbp based build. For the other points - if some project installs are broken then these are issues that must be reported to the respective bistro maintainers. I use the pkg-config for my personal plugins and it works fine in both centos 6 and gentoo!

[stahta01]

Using the packages from the Debian repo, I believe it does NOT work. No codeblocks.pc files is installed.
I will have to use my dual Linux boot to confirm this; I am building something that will take a few hours before I can reboot.

It should be there according to the files-list of codeblocks-dev for testing:

...
/usr/lib/pkgconfig/codeblocks.pc
...

Thank you, I was missing "codeblocks-dev" package; I will try the wizard and see if it works better now.

Tim S.

[stahta01]

@stahta01:
If I remember correctly the new project wizard has two targets one uses the pig-config file and the other is meant to be used with a self compiled cbp based build. For the other points - if some project installs are broken then these are issues that must be reported to the respective bistro maintainers. I use the pkg-config for my personal plugins and it works fine in both centos 6 and gentoo!

The wizard uses pkg-config for both targets; I think one of them should NOT use pkg-config codeblocks and do it using the CB contrib project way or using the CB global variable.

Tim S.

[stahta01]

Using debian built codeblocks.pc:

I had to add "-std=c++11" to get wizard to build; should this be added to the wizard or not?

Tim S.

[oBFusCATed]

For the record the patch from https://sourceforge.net/p/codeblocks/tickets/481/ is applied in this branch https://github.com/obfuscated/codeblocks_sf/tree/plugin_wizard
Please test and provide suggestions and further patches.

@bluehazzard: I'm not sure I like the current set of targets.
In fact I think that we need 3 or 4 targets:
1. on for linux for the codeblocks installed on the systems that uses pkg-config codeblocks
2. cross platform target for wx2.8 that uses the cb variable
3. cross platform target for wx3.0 that uses the cb variable
4. optional - and another one for wx3.1

This way a plugin developer can test his/her plugin against all versions of codeblocks and the setup will be relatively easy.

I'm not sure that I like the sandbox notifications for the new copy scripts used for copying dlls. Can't we output the file directly where it will be used?

@jens: Do you think it will be a good idea to modify pkg-config codeblocks to return compiler/linker flags related to the proper wxgtk that should be used? This way a plugin will always be build with the correct wxgtk library.

[BlueHazzard]

2. cross platform target for wx2.8 that uses the cb variable
3. cross platform target for wx3.0 that uses the cb variable

is a cross platform project even possible?

[oBFusCATed]

Bleh... I've not meant cross platform as working on both windows and linux.
I've wanted to write "target that installs inside the build folder of codeblocks".

I have some fixes which will make it possible to build and debug the plugin on linux...

[oBFusCATed]

I've pushed two more commits to the branch. I think the wizard now works well on linux. Someone should test and do modifications that make windows work as well.

What I've done:
1. Make only the default target to use the supplied wxversion option
2. Create two targets to_codeblocks_wx28 and wx30. They use hardcoded wx-config --version commands, because they are targeting specific version of CB. Also don't use `pkg-config codeblocks` for them, only for the default target. Instead use paths inside the cb folder.
3. Change the objs folder.
4. Remove the IO.Copy. I don't like it, because every time it asks for permissions, if there are errors it doesn't print anything in the log and lastly we can output the file where it is supposed to go.
5. Add no-undefined and --no-ipc flags.
6. Add All target that can be used to build everything in one go.

So please test and patches welcome...

Edit: See the attached for the project that is generated on linux with the changed version of the wizard.

[BlueHazzard]

Ok, i tested the windows script of the plugin.
Here some things i found:
1) On windows the to_codeblocks28 and to_codeblocks30 does not work with this configuration, because both builds use the "wx" global variable for the wx library path. So for the to_codeblocks30 there is a global variable with the name "wx30" needed and used for the library and include search paths
2) Same for the library path to the codeblocks library. Now it is "$(#cb)\devel" for both targets, but it should be "$(#cb)\devel" for "to_codeblocks28" and  "$(#cb)\devel30" for "to_codeblocks30"

I see that the correct libraries and paths are used if i select a other wx configuration. So The question is how should this be handled? Simply do not make a choose between different wx configuration and use all targets?

In general all seems to work. I can build, run and debug the generated projects

[oBFusCATed]

For to_codeblocks_wx28 and wx30 the choice of wx should not matter. They should use the correct variables, which are the same used for the version of cb that is targeted. The choice of wx should be important only for the default target.

[BlueHazzard]

Ok, i made a pull request https://github.com/obfuscated/codeblocks_sf/pull/7

A other thing to add would be the possibility to import a existing plugin, or to create a empty plugin, for the platform, so that it gets easy to import a existing plugin project from a other target system.
The easiest way would be to simply create a empty project with all needed compiler settings but no files. The user can then import all the files he needs at once.

any thoughts on this?

[oBFusCATed]

any thoughts on this?

I'm not sure what problem you have in mind.
We need a way to add targets to existing projects, but I think we have more serious problems to tackle.
Creating plugin project is not something cb users do everyday.