User forums > Using Code::Blocks

CodeBlocks and contrib projects for MacOSX 10.4

(1/4) > >>

bnilsson:
With some help from Pecan I have adapted a .cbp projects that builds CodeBlocks and contrib plugins on MacOSX 10.4 using CodeBlocks.

What came as a surprise to me was that the frontpage buttons and icons (New project, Open project, Recent projects, etc.) was working instantly on CodeBlocks built by the CodeBlocks-mac104.cbp, while these functions are not working (at least for me) when building CB from command line.

The attached package also contains a modified update script (update-mac) plus a bundle script to make a CodeBlocks.app bundle.

Test it with care, so you don't ruin existing installations.

 

[attachment deleted by admin]

Game_Ender:
Are these going to be submitted to as patches for CB?  I am starting a project at my university and I have several Mac team members.  It would be a great boon to the project to only have to support one C++ IDE.

takeshimiya:
Hi,

this is nice, it would be even nicer if it could be mantained by someone with commit access over svn,

the unix cbp's are almost the same, with some differences, so you could
a) maintain a set of patches to output -mac.cbp's based on the -unix.cbp's
b) maintain a different set of projects (lot of burden maintenance)
c) maintain a sed script to output -mac.cbp's based on the -unix.cbp's.
d) maintain a set of build scripts (squirrel) for the -unix.cbp's (this is the one I like most)


some things to note in the projects attached:
1) you use
<Option output="devel/libwxscintilla.dylib" prefix_auto="0" extension_auto="0" />
but it is not necessary, the idea is to use prefix_auto="1" and extension_auto="1" so CodeBlocks guesses the prefix and extension automatically,
so here, we cut the "diff" a bit,

2) I can see that you use sometimes <Add option="`wx-config --libs`" /> in both the Projects and the Targets, it is not necessary to be in both, just use one of the two, and leave the same as the -unix.cbp's

3) there is <Add option="-D__WXMAC__" /> usage,
question: doesn't wx-config --cxxflags defines that automatically?

4) I see inclusion of <Add directory="/usr/lib" /> and <Add directory="/usr/local/lib" />,
for which library is this necessary? if for wx, that's not good,
the problem in hard-coding this system path in the project is that, for example, if you want to use the wx from MacPorts (/opt/local/lib) the above path will override it; I think it's better to leave the user to define those system paths in their own linker paths.
linking to /usr/lib/libSystem.dylib directly is rather OK because you don't bring all the paths to the linker

bnilsson:
Thanks for the comment, I will implement the suggested changes.
I got the project from Pecan as being 10.3 compatible, and after I got it to build without errors on 10.4.8, I did not proceed much further.
I will send an updated version as soon as I see that it is working with your suggested changes.
Any further comments will be much appreciated.

bnilsson:
I was able to do away with 3) and 4) but not 1) and 2).
1) libwxscintilla apparently needs to be a .dylib, automatic extension makes it a .so, and this does not link. I did not see auto prefix do anything at all.
2) removing `wx-config -libs`from "sdk" and "src" targets caused link errors against wx.

Major other changes to fix the above I guess would be contraproductive if the issue is to have as little differences as possible vs. -unix.cbp.
But of course, suggestions are welcome.


I will go thru the plugins/contrib projects also to see if I can remove some unnecessary stuff there also.

Navigation

[0] Message Index

[#] Next page