Author Topic: Upgrading codeblocks using darwinports + wiki instructions  (Read 6139 times)

bnilsson

  • Guest
Upgrading codeblocks using darwinports + wiki instructions
« on: October 01, 2006, 06:09:18 pm »
I have managed to install a more or less working copy of CodeBlocks using the wiki instructions for Darwinports installation.
However, I experience some serious bugs in rev 3001 I would like to follow the development and see these bugs fixed.

I see now that we have rev 3002, but the command "port upgrade devel/codeblocks" is not detecting any changes, and updates nothing.

Is there a way to get darwinports( or MacPorts as it is called nowadays) to upgrade codeblocks?

Manual build also works for me, but I have not yet been able to create a working CodeBlocks.app bundle "manually" using the wiki instructions. I would need to get some VERY detailed instructions on how to create a working CodeBlocks bundle from a "svn update", ./bootstrap, ./configue and make. This would help me to be updated.

The darwinport version is using symlinks from the bundle to the installation in /opt/local.
In my manual build, I use --prefix=$HOME not to interfere. In my bunding attempt I try to use symlinks to ~/bin/codeblocks etc., otherwise I try to follow the wiki instructions. The problem is that CB does not find the plugins.

We've been thru this in a similar thread, but it seems we have to start all over.


Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Upgrading codeblocks using darwinports + wiki instructions
« Reply #1 on: October 01, 2006, 10:37:41 pm »
I see now that we have rev 3002, but the command "port upgrade devel/codeblocks" is not detecting any changes, and updates nothing.

I think that all builds are called "1.0_0" (for SVN), so you will
need to force a rebuild of the package first (i.e. make it fetch).

Quote
Is there a way to get darwinports( or MacPorts as it is called nowadays) to upgrade codeblocks?

I'm going to continue to call it DarwinPorts until they have a clear roadmap...
There should be some way to make it use the SVN revision as a subrelease ?

Quote
Manual build also works for me, but I have not yet been able to create a working CodeBlocks.app bundle "manually" using the wiki instructions. I would need to get some VERY detailed instructions on how to create a working CodeBlocks bundle from a "svn update", ./bootstrap, ./configue and make. This would help me to be updated.

I'm working on a script to do it, and will update the wiki with further info.
Just thought that we could get some of the patches included upstream first...

Quote
The darwinport version is using symlinks from the bundle to the installation in /opt/local.
In my manual build, I use --prefix=$HOME not to interfere. In my bunding attempt I try to use symlinks to ~/bin/codeblocks etc., otherwise I try to follow the wiki instructions. The problem is that CB does not find the plugins.

For a custom bundle, you can put everything from share/codeblocks into Resources of your application bundle. Compare with the nightly build, to see how that is layed out ?

bnilsson

  • Guest
Re: Upgrading codeblocks using darwinports + wiki instructions
« Reply #2 on: October 02, 2006, 09:48:13 am »
Some more questions:

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?

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.

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.
What about "cb_console_runner"?
And should everything in lib be moved or only "libcodeblocks.0.0.1.dylib".
Is "libcodeblocks.la" also a dynamic library?

As I indicated in the first post, I tried to replicate what you did in the port, by investigating /Applications/Codeblocks.app/Contents, and also by trying to understand the contents of the Portfile. I think I get the most of the story, except the very last "post-install".
Anyway, starting the manually built bundle giver one error dialog window saying "<pluginname>.zip not found - check your installation" for each plugin.
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;

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?




Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Upgrading codeblocks using darwinports + wiki instructions
« Reply #3 on: October 02, 2006, 11:35:11 am »
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.

Quote
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)

Quote
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.

Quote
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?)

Quote
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.

Quote
Is "libcodeblocks.la" also a dynamic library?

.la files (a text format) are for GNU libtool. I just delete them.

Quote
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.

Quote
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!

Quote
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.

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Upgrading codeblocks using darwinports + wiki instructions
« Reply #4 on: October 02, 2006, 11:46:43 am »
I think for "cb_console_runner", the best thing would be to make
a PKG for it and include that into the .app application bundle itself ?

Then you could have a menu option like: "Install Command-Line Tool",
that would install the Terminal program by just opening this .pkg file ?

Code
/usr/bin/cb_console_runner
/usr/share/man/man1/cb_console_runner.1

It seems that it doesn't need libcodeblocks.dylib, which is good...
We could install it into /usr/local, but /usr/local/bin is not in $PATH.

If you don't have permissions for /usr (admin), it's a flip of a switch
to make the pkg install the files to another $PREFIX of your choice...

On second thought:
The program is only needed by the application (not called by the user),
so it is probably OK to just put in the "MacOS" dir inside the bundle ?

We need to look at this more carefully anyway, since Terminal.app
does not have a -e switch like xterm has (maybe AppleScript? <yuck>)
« Last Edit: October 02, 2006, 05:33:27 pm by afb »

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Upgrading codeblocks using darwinports + wiki instructions
« Reply #5 on: October 02, 2006, 11:53:15 am »
Another thing to consider is whether we want the application to link towards an external "wx.framework", instead of including the wx libraries in the bundle itself...

I didn't want to do an internal framework, since wx comes with almost 20 MB of header files that seemed redundant if you couldn't use it from your own projects anyway ?

libwx_mac-2.6.0.3.1.dylib is 14M (unpacked) for the Universal Binary, so that's 33% of the entire application bundle. But DLL Hell with wx versioning isn't very fun either...

bnilsson

  • Guest
Re: Upgrading codeblocks using darwinports + wiki instructions
« Reply #6 on: October 03, 2006, 12:24:55 am »
I downloaded rev 3002 fresh, applied patches,
./bootstrap
./configure --enable-contrib --prefix=$HOME CXXFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib
make
make install

and moved all (bin,lib,share/codeblocks) to MacOS and Resources according to wiki.
cd Contents/MacOS
install_name_tool -change ~/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib CodeBlocks
install_name_tool -id @executable_path/libcodeblocks.0.dylib libcodeblocks.0.dylib

Started CodeBlocks but no plugins found.
A yellow popup message window reported a "list of failed plugins: lib<pluginnames>.so" .

Any suggestions?


Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Upgrading codeblocks using darwinports + wiki instructions
« Reply #7 on: October 03, 2006, 01:05:17 am »
Sorry, haven't yet added to the Wiki that you should change
*all* of the libraries (.dylib) and bundles (.so) not just one...
So you should repeat the process for your plugins, or they
will look in the wrong dir for their libs (check with otool -L)

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Upgrading codeblocks using darwinports + wiki instructions
« Reply #8 on: October 03, 2006, 01:17:31 am »
If you find it easier while debugging, you can just leave the
binaries and libraries under /usr/local and set up symlinks ?
(and this is what the DarwinPorts build does, for wxMac build)
Alternatively you can avoid the bundle and use the old Rez.