wxSmith develpers: Intergation of new items in Linux build

[MortenMacFly]

Dear developers interested in wxSmith,

I've setup a SVN branch for a while now that integrates a lot more wxSmith items contributed by several people. All that's needed is the integration into the Linux automake system and an update of the C::B Linux/Unix project files. One this is done we can merge the items into trunk.

So, if you know "autofoo" and are willing to contribute, checkout the branch at:
http://svn.berlios.de/svnroot/repos/codeblocks/branches/wxsmith_addons
and start updating the build system (see the other wxSmith items as a reference). Any help is greatly appreciated.

Question are welcome (of course).

[oBFusCATed]

I can tackle this problem, my auto-fu is not that good, but it is improving, unfortunately:)

What is the plan for the merge? Will it be replacing or you'll try a proper merge?

[Jenna]

I can probably do it this weekend or during the next week (I will come back from work this night, very, very latey).

[oBFusCATed]

Jens: I'll give it a try and if I fail, I'll post, so you can do it:)

[MortenMacFly]

What is the plan for the merge? Will it be replacing or you'll try a proper merge?

I would do a plain "copy", not a proper merge. In the end it's an addition of several plugin/components, only. So I don't want to resolve a million conflicts just for the sake of perfectionism. ;-)

BTW: Interesting to see devs call "here", I actually addressed the community. Oh - and keep in mind that some additions are incompatible to Linux, like IExplore...

[oBFusCATed]

OK, started with the first one alphabetically, wxSmithButton...

Here is a rough patch for linux (I guess I've broken the windows build, no time and energy to try it there): http://smrt.is-a-geek.org/codeblocks/patches/wxsmith/wxsmithbutton.patch

Does this thing work on windows? There are some mismatches in the manifest and name of the generated library. I've fixed them, and renamed the thing to wxSmithButton.

[Jenna]

@MortenMacFly:
There are many differences in the projectfile(s ?) between the branch and trunk.
It seems some of the merges did not really succeed.

Neither the windows nor the linux core-project-file should be compilable (linux is  definitely not [LexModula.cxx is missing from cbp-file]), and the prefix-extension-stuff is quite different between both versions.

I did not check other parts for inconsistencies, but I think this should be fixed first.

[MortenMacFly]

@MortenMacFly:
There are many differences in the projectfile(s ?) between the branch and trunk.
It seems some of the merges did not really succeed.

Mmmh... are you sure you didn't miss a SVN update / clean checkout? I checked out both: trunk and the wxSmith branch and compared them with a comparison tool. They are the same except the changes for wxSmith related plugins. :shock:

[Jenna]

My local copy was broken for unknown reasons  :? .
After a freash (clean) checkout, everything seems to be okay now.

[Jenna]

As first, we should decide, whether we want one project-file for windows and one for linux (like the most contrib-plugins have) or one for both with targets for windows and linux.
 I personally prefer the first solution, because it's to maintain (in my opinion) and looks more clear.
Otherwise we would need targets like:

• SpeedButton - Windows
• SpeedButton - Linux
• wxSmithButton - Windows
• wxSmithButton - Linux

[oBFusCATed]

As far as I can tell contrib plugins use both schemes: there are plugins having two cbp files and there are plugins with a common cbp.

[MortenMacFly]

there are plugins having two cbp files and there are plugins with a common cbp.

IMHO only one plugin uses the platform flag (wxAUI) as tech demo -> so please, leave it as it is for this plugin. The other should have two project files, one for Linux, one for Windows.

[oBFusCATed]

Understood...


BTW, Why don't we put the new things in the wxSmithContrib plugin or in a contrib2 plugin.
Having one plugin for SpeedButton seems like an overkill (it even creates its own toolbar in the interfaces )