The current darwinport installation prescribes some patches, which are available on the wiki page. As the project develops, I assume that these patches may or may not be applicable since they may already be implemented. There may also be new patches required. How do you handle this?
I will try to label the patches with the revision that they applied to,
and will update them when I make a "nightly" (i.e. stand-alone zip)
As you might have noticed, all patches are on my home page anyway.
The wiki instructions on how to make a bundle is very different from how your darwinport is doing it.
The method described in the wiki is moving the complete installation hierarchy into the bundle, while your port is making symliks to the installation in /opt/local. You may want to comment on this.
This is on purpose, Mac OS X and DarwinPorts uses different philosophies...
The stand-alone version includes
everything into the application bundle,
while the port links towards the system libraries (much less redudancy)
The wiki bundle description is not perfectly clear as I see it.
For instance, why is the last three lines in the hierarchy list written in italic?
Under "Proper bundling" you write that codeblocks and the dynamic libraries should be moved to MacOS from bin and lib.
The last three in the hierarchy is an interim step (i.e. a hack),
much like the symlinked application bundle in DarwinPorts is.
What about "cb_console_runner"?
We can make the DarwinPorts installation include it, under /opt/local/bin.
For the Mac OS X installation, it will need to go separately (/usr/bin perhaps?)
And should everything in lib be moved or only "libcodeblocks.0.0.1.dylib".
Everything. The bundle shouldn't have any "bin" or "lib" or "share", really.
Is "libcodeblocks.la" also a dynamic library?
.la files (a text format) are for GNU libtool. I just delete them.
I think I get the most of the story, except the very last "post-install".
I was trying to make the wxMac version work without the .app bundle.
It works crappily on Intel Macs, so I will probably remove it altogether.
Could you describe exacltly what steps are required to make a manual symlink bundle work?
This is mainly for two reasons:
1) It is quicker for me to "update by make" since darwinports update would require a full rebuild;
2) I have a chance to participate in the debug process (not very likely, but anyway) since I have access to source code and make output. I am hesitant to mess around with the /opt/local, I have had serious port problems before when I did this;
I will update the Wiki with more information, and am now running Intel!
How does CB decide where to look for the resources?
The "wiki bundle" looks for it in Contents/share/codeblocks, while the "symlink bundle" looks in Contents/Resources. Still the source code is the same?
The logic is something as follows:
- Find the location of the current application "Resources" directory,
if not bundled this will return the location of the application itself - If the location contains "/Resources", use it
- Otherwise, look in "../share/codeblocks" (relative to the bin folder, that is)
Only downside is that it only works if you call the program with a full path,
like /opt/local/bin/codeblocks and not if you only do a "codeblocks" call -
since then it will look in the parent of the current directory instead of $PREFIX.