Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Will patches to compile and link C::B against wxWidgets 2.7.1 be accepted?
takeshimiya:
--- Quote from: afb on November 02, 2006, 12:32:49 am ---There is no wxWidgets.framework. Tiger ships with wxPython 2.5 - as libraries.
I think that Leopard would be better off with wxPython 2.7 as libraries too, but...
--- End quote ---
I see, also probably it's not worth using what the system haves, as you have more control on which wx version to use;
about the other thing, it probably depends if you are more on the BSD side or the Apple side of Mac :P
takeshimiya:
Hi,
--- Quote from: afb on November 01, 2006, 10:49:30 pm ---The 3164 build is uploaded to BerliOS now
--- End quote ---
I've tried the build and it worked, I could compile for the first time from CB :D
Of course there are a lot of little/medium issues still, but it at least serves as a build system,
The first thing I found is that I couldn't run C::B because some previous setting in default.conf was bad,
and here comes the problem: the file is located in ~/.codeblocks, so I didn't have any way to access it (not from Finder nor terminal). I know that some programs let's you enable "see hidden files" but it's not the point and I didn't have one at hand,
I propose to use APPDATA as ~/Library/Application Support/CodeBlocks/ which is what most crossplatform/opensource programs are using (non-crossplatform programs tend to use ~/Library/Preferences because they don't have problems in using the plist format),
The other problem is when compiling, I get occasionally this error Message box (it gets compiled nonetheless):
can't flush file descriptor 16 (error 45: Operation not supported)
afb:
I prefer to use the cross-platform locations like /usr/local/lib/libwx_mac-2.6.dylib and ~/.codeblocks, but I can probably be talked into changing those to /Library/Frameworks/wxWidgets.framework and ~/Library/Application\ Support/CodeBlocks to work with the venerable Finder...
I still suggest /Developer/Applications/CodeBlocks.app as the location for the program. (that is, what use to be /usr/local/bin/codeblocks) Some of the wizards also needs to be redone to understand frameworks, such as the ones for OpenGL/GLUT and wxWidgets...
takeshimiya:
--- Quote from: afb on November 02, 2006, 06:33:13 pm ---I prefer to use the cross-platform locations like /usr/local/lib/libwx_mac-2.6.dylib and ~/.codeblocks,
--- End quote ---
Those are "unix" locations, in Windows you have them in C:\Program Files\CodeBlocks\wxmsw26u_gcc_cb.dll (usually) and %APPDATA%\codeblocks,
in Mac I also like to have libraries in /usr/local/lib/ (because I use MacPorts), but for bundles (.app) it would be ugly to have them in /usr/local/bin and similar places.
--- Quote from: afb on November 02, 2006, 06:33:13 pm ---but I can probably be talked into changing those to /Library/Frameworks/wxWidgets.framework
--- End quote ---
It's also fine as currently, if the mac dylib is inside the bundle,
--- Quote from: afb on November 02, 2006, 06:33:13 pm ---I still suggest /Developer/Applications/CodeBlocks.app as the location for the program.
--- End quote ---
Yeah, it's more standard than /Applications in this case and /Developer/Applications is more well suited (Xcode is there),
however since C::B is distributed as a bundle, that's a users choice,
--- Quote from: afb on November 02, 2006, 06:33:13 pm ---(that is, what used to be /usr/local/bin/codeblocks)
--- End quote ---
I think that location can be fine if you build it from MacPorts, but /Developer/Applications is fine too,
--- Quote from: afb on November 02, 2006, 06:33:13 pm ---Some of the wizards also needs to be redone to understand frameworks, such as the ones for OpenGL/GLUT and wxWidgets...
--- End quote ---
Yes, there's a lot of work to be done
afb:
--- Quote from: takeshi miya on November 02, 2006, 06:49:33 pm ---Those are "unix" locations, in Windows you have them in C:\Program Files\CodeBlocks\wxmsw26u_gcc_cb.dll (usually) and %APPDATA%\codeblocks,
in Mac I also like to have libraries in /usr/local/lib/ (because I use MacPorts), but for bundles (.app) it would be ugly to have them in /usr/local/bin and similar places.
--- End quote ---
Fair enough, let's move them to the Mac locations (I think wx has some helpers)
MacPorts normally installs in /opt/local, though - but let's not mix that in here...
--- Quote ---
--- Quote from: afb on November 02, 2006, 06:33:13 pm ---but I can probably be talked into changing those to /Library/Frameworks/wxWidgets.framework
--- End quote ---
It's also fine as currently, if the mac dylib is inside the bundle,
--- End quote ---
I had planned to separate it, in order to cut down the size of the nightly and also in order for the user to be able to develop new program for wxWidgets with it ?
--- Quote ---
--- Quote from: afb on November 02, 2006, 06:33:13 pm ---I still suggest /Developer/Applications/CodeBlocks.app as the location for the program.
--- End quote ---
Yeah, it's more standard than /Applications in this case and /Developer/Applications is more well suited (Xcode is there),
however since C::B is distributed as a bundle, that's a users choice,
--- End quote ---
It definitely is, and they can also put it in ~/Library/Frameworks and ~/Applications if they do not have admin priviledges on the machine ?
--- Quote ---
--- Quote from: afb on November 02, 2006, 06:33:13 pm ---(that is, what used to be /usr/local/bin/codeblocks)
--- End quote ---
I think that location can be fine if you build it from MacPorts, but /Developer/Applications is fine too,
--- End quote ---
MacPorts will install in /Applications/DarwinPorts and /opt/local, all according to their guidelines. The stuff in /Applications/WhateverPorts will be symlinks or scripts that use the regular installation (it just allows for easier access).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version