Compiling on a remote system (using a CB tool that runs ssh)

[johanekdahl]

To better understand the questions you might need some context. Bear with me...

Background: I am involved in developing an embedded application. The embedded s/w is built on a Linux system. Compiler is GCC. My workstation is a Windows system. Up until now I have used Code::Blocks on this Windows system to edit the files on the Linux system. I then do "Save all" in C::B, switch to a PuTTY session to the Linux system and do the build. Getting errors I have to go back to C::B and locate eg. a syntax error "by hand".

So today I talked with one of our Linux gurus who helped me out. We took advantage of Cygwin being installed on my Windoze system, and after some tests I thought I saw an opportunity to get a much more streamlined process.

I have set up a tool in C::B like this:

Name: Build
Executable: C:\cygwin\bin\ssh.exe
Parameters: myUserName@theLinuxSystem make -C pathToMakefileDirectory
(*) Launch tool hidden with standard output redirected

This enables me to activate a build from within C::B.

And now the questions / troubles I still have:

1. Is there a way to get all files saved automagically before a tool is executed?

2. Errors in the build are coming back to the Code::Blocks tab of the Messages window like this:

Code

stderr> ../Frameworks/ClassLib/PropertyLib/PropertyContainer.cpp:283: error: `unlnk' undeclared (first use this function)

Is there a problem with C::B parsing this so that I can double-click on the error message in order to get the editor to go to that line? Or is that functionality not present in the Code::Blocks tab? Or...?

If you see what I am aiming at (a "remote build with locally usable error messages in one click"), then you might have advice on another way to achieve this?

[MortenMacFly]

2. Errors in the build are coming back to the Code::Blocks tab of the Messages window like this:

Code

stderr> ../Frameworks/ClassLib/PropertyLib/PropertyContainer.cpp:283: error: `unlnk' undeclared (first use this function)

For this you need to adjust the RegExp in the advanced compiler options: Settings -> Compiler and Debugger -> Tab "other settings" -> Button "Advanced options" -> Tab "Output parsing" -> Compiler error.
Change the rexexp to have "stderr> " in fron that does not get matched and it should work. The same applies for the other parser options that may be affected.
Notice: For testing you can use the "Regular expression testbed" plugin of C::B. ;-)
With regards, Morten.

[mariocup]

Hi,

perhaps this link could be interesting for you.

http://wiki.codeblocks.org/index.php?title=Installing_Uniwin_remote_compiler

Bye,

Mario

[johanekdahl]

Morten!

Thank you for the quick answer. I realized I was running a too old version of C::B for the options you are referring to (I was running build 3459). So I tried to upgrade to the latest nightly, but ended up with everything broken...

What I did:

Unpacked all three 7zip-files to the same directory where the old C::B installation was. Answered "yes to all" for replacing files/folders with the same name.

What I get:
Many plugins that fail to load.
Notice about errors loggd to the log files.
A "Script run error" error box.
A startup screen that is more or less "fubar".
And when I try to access the settings you referred to C::B crashes when i click the "Advanced options" and answer the warning that follows.

I then tried to remove the share folder and unzipped again, but to no avail.

I then renamed my current C::B folder, created a new one and unzipped to there. Still the same errors.

Any advice?

(Almost every time I upgrade I have these problems, and that is why I upgrade so seldomly. I really, really, really wish for a foolproof installation program. And yes - I know that the answer is that I should write it myself... :wink:)

[johanekdahl]

Mario!

Thanks for the tip, looks really interesting. I'll dig deeper into it when time permits!

[johanekdahl]

Solved some of the upgrade problems:

I needed to copy the share folder to
    C:\Documents and settings\myUserName\application data\codeblocks

I seem to recall that I stumble on this every time I upgrade. Absolutely nothing about this is mentioned in the post about installing a nightly ( http://forums.codeblocks.org/index.php/topic,3232.0.html ).

So now C::B start up without errors again (phew!), but I still have the old dialogue where the setting that Morten mentioned is not present. In fact, there are no tabs at all, and the only thing present in the left column is "Batch build".

[johanekdahl]

Solved more of the problems: Making a new shortcut made the new correct tabbed dialogue box re-appear (no idea why...).

So now I can start tinkering with this parsing of errors. To restate, an error message looks like this:

Code

stderr> ../Frameworks/ClassLib/PropertyLib/PropertyContainer.cpp:283: error: `unlnk' undeclared (first use this function)

Note that the makefile is not at the root of the source/project tree. This is necessary as we are building for several different targets ("production build" for the actual target, "unit test build" targteted/executed at the same system as the build is taking place on, etc. All of those builds have their own configurations so we cannot let the build spread over the source tree.) This is why the error starts with "../" .

So now I have this regexp:

Code

stderr> \.\./([][{}() \t#%$~A-Za-z0-9_:+/\.-]+):([0-9]+):[ \t](.*)

and it does not work (nothing happends when double-clicking it). Anyone spot the mistake that I am blind for?

And to re-iterate: Tools have their outputs go to the Code::Blocks tab (NOT the "Build messages" tab) in the Messages window. Is this tab really sensitive to double-clicks?

(If the answer is actually yes, then would you suspect that Alt-F2 also works? My speculation is that both the double-clicking and Alt-F2 works only in the "Build messages" tab.)

[johanekdahl]

Mario!

Took another look at Uniwin. It seems to me that it is intended for having the "original" source tree on the Windows system. Uniwin will then "synch" a that tree with a copy on the Linux system where the build will take place.

I actually have the original tree on the Linux system.

Running Uniwin would synch a tree that is actually on the Linux system with a copy that is also on the Linux system. We are talking about a few thousand source files (.cpp and .h), that has to be synched generating network traffic over my Windoze system.

I also could not find out how to direct Uniwin to use a certain toolchain on the Linux system (yes there are several toolchains present, and I suspect that the Linux-gurus have tweaked the configure-scripts to use the correct one for building for the real target or building for unit tests etc). Come to think of it, isn't it so that you actually will be using C::B's internal build system rather than anexternal makefile. If so then Uniwin is definitely out, as there are loads of specialities in our makefiles. Building with them is an absolute must!

[johanekdahl]

So, anyone have an answer for my first question: Is there any way to get C::B to save all files before running a tool?

[rickg22]

johanekdahl:

Right idea, wrong tool.

Instead of configuring a tool, you should define a new compiler. This way you can compile with your remote compiler. The custom compiler setup is just like "tools", except it has a different command line for compiling, linking, etc.

[dmoore]

johanekdahl:

Right idea, wrong tool.

yeah, I was wondering how compiler output parsing regexes would affect the code::blocks message log...

[dmoore]

So, anyone have an answer for my first question: Is there any way to get C::B to save all files before running a tool?

setting up a compiler will also solve this problem...

hmm... I do wonder whether the compiler framework will be able to handle communication over a persistent ssh session (e.g. pre/post build commands would by default run locally instead of on the remote host)

[johanekdahl]

Before entering on the adventorous path of setting up a new compiler:

Are suggesting to use the C::B internal build system. It seems to me that this will not work.

I need (as in must) build on the remote system with a makefile (several actually) that resides in that tree. If doing this by setting up a compiler in C::B implies that C::B's build system will be used then I will have to

1) Figure out how the makefile(s) are structured,
2) Figure out how to get the same from the C::B's build system, and
3) Maintain the setup in C::B's build system whenever the makefile(s) change, but
4) There is no mechanism in place in the organization to signal that someone changes something in the makefiles(s).
Also, in my C::B projects I might not even have all files that are actually in the build. Some of the code I never work with. Having to maintain these files also does not make sense for me. It seems to me that using C::Bs build system is not feasible.

So I'm using C::B as a "super-editor" rather than an IDE. It does this very well (the alternative was to pay for SlickEdit and there was no funds at the time, and I was not overly impressed by some of it's features).

When I started this thread I was looking for a mechanism that
1) Did a "Save all",
2) Ran a "make" command on a remote system,
3) Captured the result, and
4) Handled this result so that I could navigate to an error with ease and prescision.
I got points 2 and 3, and that is more than what I had two days ago!

I was hoping to make the "compile for syntax/sematic errors" step a little more streamlined, but if it's not possible I still am one happy developer: I have gotten quite fond of C::B during these nine months. It does the editing job very well. It has the class browsing I desperately needed.

If my rant above is mumbo-jumbo, and it actually possible to tell C::B to execute a "make" command on a remote host by setting up a compiler in C::B, how would I go about doing that? Any hints?

Next step was to have C::B as a debug front-end (application running in the embedded system, GDB running on the Linux system and C::B on my Windoze workstation being a front end for that). Feasible?

[dmoore]

You can setup a project to run pre/post build scripts. Those scripts get parsed for errors in the same way gcc and ld do... so why not try making a call to your ssh/makefile script a step in your pre/post build?

[dmoore]

you can also specify that build scripts always run