User forums > General (but related to Code::Blocks)

CodeBlocks being called from hudson (on linux)

<< < (3/10) > >>

Jenna:

--- Quote from: killerbot on December 30, 2010, 12:00:27 am ---that did start a CB, but strange stuff, both my monitors turned black, in the upper left corner you could see the CB starting and the plugins loading (as you would get when starting CB in shell), then again in the upper left part CB became visible (like a very first start if CB) and saying it detected the compiler. But no project was building ...

Tried it a second time, same thing. Seems this is not yet the solution.


EDIT : I called the same thing in a regular shell, just for testing purposes :

--- Code: ---xinit -e '/usr/local/bin/codeblocks --no-check-associations --no-dde --no-splash-screen --rebuild --target=Debug Arrays/Arrays.cbp' -- :101
--- End code ---

The screens turning black, and then CB visible (no compiler detected window here).

--- End quote ---
Remove --no-check-associations and --no-dde (or use --no-ipc for the second), because they are windows arguments and seem to break the batch-build.
I think it should build anyways, but at the begin of the log messages you have "unknown long-option ...", so it might be a wxWidgets problem.

Jenna:
By the way: the monitors turn black, because a new xserver is started and xinit switched to it.
If you don't want that, you can run an alternative xserver like Xvnc to run xterm in.


--- Code: ---xinit -e '/usr/local/bin/codeblocks --rebuild --target=Debug Arrays/Arrays.cbp' -- /Usr/bin/Xvnc :101
--- End code ---

In all cases you have to switch to the correct directory before running the command ,of course (or use full path).

killerbot:
Thanks, we are getting somewhere

1) when launching the xinit/Xvnc from the shell : works and no black screens (minor issue could be I don't see the build window, but it might be good not to show that, however when something terribly might go wrong and CB pops up a message box,that message box will not be visible I guess, and such can not be clicked)

2) when hudson will issue this command, it is not succeeding, since it is showing that compiler detected dialog box, which need to be clicked, and as such the build never finishes.

killerbot:
A little recap :

CB is a strong IDE, but it is also a strong build tool (focusing now on command line usage) :
- feed it a workspace, and it can build all projects
- feed it a project, and it can build *all* targets [ONLY if there is a virtual target bundling all the targets] [IDEA : I think when no target is specified all targets should be build] Any comments ???????
- It can run post build things, either by ,anual commands or by launching several plug-ins (for example run a CppCheck)

As such it can be a good replacement for make files, especially towards continuous integration. Where continuous integration would be configured by a shell script to launch the correct makefiles, it now could be configured to call CB.

I have done long time ago such things on windows, where the CI hudson was calling a 'driver program' which in turn called CB (that driver program created for example the correct config spec for clearcase depending on certain criteria), but forget about windows, time to focus on linux.

There are 2 ways of running hudson :

1) under your regular user account during your regular sessions, you fire up a shell and start the hudson.war manually [java -jar hudson.war]. Hudson will store all it stuff in '.hudson' directory in your home directory
GOOD :
 - no issues as described above in the previous replies, there's an xserver, the build window is even visible
BAD :
 - it is not automatically started, after each login you need to open up your shell and reissue the command to fire up the hudson.war
Question : I guess this can be automated (how exactly ?)

2) install a package for your distribution, this will also activate a startup script (for me : OpenSuse ->/etc/init.d/hudson, with a config file /etc/sysconfig/hudson), the hudson stuff now ends up somewhere under /var/lib/hudson and /varr/log/hudson) and it is being launched by the startup script as the user 'hudson' which is a member of the group 'hudson'
GOOD :
 - automatically launched
 - dedicated user for this
 - no need to log in with a certain user account
 - really a server/service
BAD :
 - those gtk issues / xserver issues pop up as described in the previous replies :-(

I tried in the configuration to say the hudson daemon should be run by my account (HUDSON_USER="killerbot") but that didn't help, the issues remain.

So the closet was thet xinit/Xvnc thing but that also fails now due to the compiler detected dialog box invisibly waiting to be clicked ...

Jenna:
The compiler detection dialog only pops up once, if hudson could save the default.conf, but I guess it has no home-directory and so no default place (that is writable) to store it.
A workaround is to copy a working default.conf (or any other *.conf for C::B) to the location where your executable is (for example as hudson_cb.conf) and start C::B normally, or in second case with the personality you use as parameter.
If it is started from a virtual terminal (running under your X), you can also use Xephyr (if installed) as xserver. It needs xhost + to be set before. So the new xserver is started in a nested window on your desktop.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version