Author Topic: Today's updates: 30 Nov 2005 (Read 20815 times)

mandrav · « **on:** November 30, 2005, 03:49:02 pm »

Not much time today, so not many updates.

Added command-line options for batch builds.
--hidden: do not show the C::B window.
--build: build the project/workspace.
--rebuild: clean and then build the project/workspace.

The project/workspace is specified last in the command-line.
This feature is best used with personalities. Because we just want to batch-build a project/workspace, we don't need to load other plugins than the compiler. What a perfect job for a new personality

.

Small HOWTO:

Launch C::B using the command-line option --personality:

Code

codeblocks.exe --personality="Build"

When C::B starts, it will start like it was just installed.
Uncheck the "Show tips at startup".
Go to "Plugins->Manage plugins" and uncheck all plugins except the compiler.
Close C::B.
A new configuration file named "Build.conf" will be saved in your config folder.

Now, if you want to batch-build a project/workspace, launch C::B with the following command-line:

Code

codeblocks.exe --hidden --build c:\some\where\a\project.cbp
or
codeblocks.exe --hidden --rebuild c:\some\where\a\project.cbp

Now you can start those unattended nightly builds

(not quite; no build log is saved yet

).

mandrav · « **Reply #1 on:** November 30, 2005, 03:52:50 pm »

Oh, backup your default.conf file first. I haven't tested the fix to ConfigManager exhaustively yet...

EDIT: I found where this little bug was and is fixed now

killerbot · « **Reply #2 on:** November 30, 2005, 04:02:46 pm »

Super !!

Some questions :

if you specify a workspace : all projects in the workspace are build ?
Which target is build for the project ??
eg : project : 4 targets : gnu (debug ), gnu (release), MSVC (debug), MSvc(release)

rickg22 · « **Reply #3 on:** November 30, 2005, 04:04:38 pm »

Question. If you specify -batch, is the "plain and simple" personality loaded (i.e. no plugins loaded unless specified otherwise)? Is the compiler output shown in stdout?

mandrav · « **Reply #4 on:** November 30, 2005, 05:47:42 pm »

Quote from: killerbot on November 30, 2005, 04:02:46 pm

if you specify a workspace : all projects in the workspace are build ?
Which target is build for the project ??
eg : project : 4 targets : gnu (debug ), gnu (release), MSVC (debug), MSvc(release)

This is a work-in-progress. Currently it builds the whole workspace. I will add support for specifying targets though.

Quote from: rickg22 on November 30, 2005, 04:04:38 pm

Question. If you specify -batch, is the "plain and simple" personality loaded (i.e. no plugins loaded unless specified otherwise)? Is the compiler output shown in stdout?

There is no "-batch" option.
We create a new personality for this reason: to make the IDE as light as possible.
And no output yet, as mentioned above. I will have to adapt messagemanager for this. Probably later tonight

.

MortenMacFly · « **Reply #5 on:** November 30, 2005, 08:25:27 pm »

...one more time: THIS ROCKS!!!

Really: Great idea!

Morten.

takeshimiya · « **Reply #6 on:** November 30, 2005, 09:27:31 pm »

mandrav: Amazing! I can't believe, I was looking to do this very same two days ago!

Something like this:
{ wxCMD_LINE_OPTION, _T(""), _T("make-file"), _T("builds the project or file specified"), wxCMD_LINE_VAL_STRING, wxCMD_LINE_NEEDS_SEPARATOR }, { wxCMD_LINE_OPTION, _T(""), _T("make-target"), _T("makes the target specified"), wxCMD_LINE_VAL_STRING, wxCMD_LINE_NEEDS_SEPARATOR },

My intention was to redirect the Build log to stdio.
And to not start any GUI, so you could compile codeblocks --make-file=project.cbp without having X running in linux.

Also, I was thinking it would be good to have an option to list all available targets.

rickg22 · « **Reply #7 on:** November 30, 2005, 10:49:11 pm »

Well the problem I see is that the SDK assummes that there IS a main frame. Most objects are descendants of wxWindow or wxObject, messagemanager is a descendant of wxNotebook, and well, you get the idea.

The change is definitely not trivial if we want to do something than just hide the frame.

takeshimiya · « **Reply #8 on:** December 01, 2005, 12:20:24 am »

I supposed that, so...

There's any way to call the compiler dll directly, and tell it to compile?
I suppose the compiler functions are enough separated from the GUI functions (wxBase, wxCore parts doesn't need a GUI).

I don't mind if this belongs to codeblocks.exe or a separeted codeblocks-make.exe (just like MSVC 2005 does).

This way, C::B will act as a very good make alternative

mandrav · « **Reply #9 on:** December 02, 2005, 02:29:06 pm »

Added --target command-line option.
Example:

Code

codeblocks.exe --personality=Build --hidden --rebuild --target="Release" ogre_sample.cbp > build.log

Also revamped the compiler plugin and it's now using a CommandQueue. This has simplified the plugin code a lot.

Urxae · « **Reply #10 on:** December 02, 2005, 03:31:25 pm »

Quote from: mandrav on December 02, 2005, 02:29:06 pm

Code

codeblocks.exe --personality=Build --hidden --rebuild --target="Release" ogre_sample.cbp > build.log

Judging by the redirection, I presume it now also sends the build outpout to stdout? If so, you forgot to mention this.

Der Meister · « **Reply #11 on:** December 02, 2005, 03:33:01 pm »

It seems that the last changes broke the linux-version of the compilergcc-plugin. While trying to compile the recent svn-version I got this error:

Code

compilergcc.cpp: In member function `int CompilerGCC::DoRunQueue()':
compilergcc.cpp:767: error: ambiguous overload for 'operator+' in 'operator+(const wxString&, const wxChar*)(((const char*)" \'")) + cmd'
/usr/include/wx-2.6/wx/string.h:1466: note: candidates are: wxString operator+(const wxString&, const wxString&) <near match>
/usr/include/wx-2.6/wx/string.h:1467: note:                 wxString operator+(const wxString&, wxChar) <near match>
/usr/include/wx-2.6/wx/string.h:1468: note:                 wxString operator+(wxChar, const wxString&) <near match>
/usr/include/wx-2.6/wx/string.h:1470: note:                 wxString operator+(const wxChar*, const wxString&) <near match>
/usr/include/wx-2.6/wx/string.h:1479: note:                 wxString operator+(const wxString&, const wxCharBuffer&) <near match>
/usr/include/wx-2.6/wx/longlong.h:909: note:                 wxLongLong operator+(long int, const wxLongLong&) <near match>
/usr/include/wx-2.6/wx/longlong.h:922: note:                 wxULongLong operator+(long unsigned int, const wxULongLong&) <near match>
make[4]: *** [compilergcc.lo] Error 1

This is the problematic line:

Code

cmd = GetConsoleShell() + _T(" '") + cmd + _T("'");

I assume that it should look like this:

Code

cmd->command = GetConsoleShell() + _T(" '") + cmd->command + _T("'");

I don't know if it's correct and I could not test it yet but (at least in my opinion) it makes more sense than before and it compiles without any problems.

mandrav · « **Reply #12 on:** December 02, 2005, 03:44:08 pm »

Quote from: Urxae on December 02, 2005, 03:31:25 pm

Judging by the redirection, I presume it now also sends the build outpout to stdout? If so, you forgot to mention this.

Yes, I thought it was evident by the example

Quote from: Der Meister on December 02, 2005, 03:33:01 pm

I assume that it should look like this:
Code
cmd->command = GetConsoleShell() + _T(" '") + cmd->command + _T("'");
I don't know if it's correct and I could not test it yet but (at least in my opinion) it makes more sense than before and it compiles without any problems.

Yes, you 're right. I haven't built it under linux yet so I missed it. Fixed and commited now.

Der Meister · « **Reply #13 on:** December 02, 2005, 04:12:57 pm »

I just discovered another issue with that line. It encloses the command (that will be passed to the shell) with backticks ('). This makes sense but collides with the title for the shell which is also enclosed in backticks:

Code

shell.Replace(_T("$TITLE"), _T("'") + m_Project->GetTitle() + _T("'"));

(This should be line 1134 in 'compilergcc.cpp'.)

Thus I think we should use double quotes (") to enclose the title instead of backticks. This seems to work (at least in my little test).

rickg22 · « **Reply #14 on:** December 02, 2005, 04:15:01 pm »

Quote from: mandrav on December 02, 2005, 02:29:06 pm

Also revamped the compiler plugin and it's now using a CommandQueue. This has simplified the plugin code a lot.

O.O You mean *BESIDES* the cmdlinegenerator stuff you had added?

Wow! I'd love to have a look at that!

Quote from: Der Meister on December 02, 2005, 04:12:57 pm

I just discovered another issue with that line. It encloses the command (that will be passed to the shell) with backticks ('). This makes sense but collides with the title for the shell which is also enclosed in backticks:
Code
shell.Replace(_T("$TITLE"), _T("'") + m_Project->GetTitle() + _T("'"));
(This should be line 1134 in 'compilergcc.cpp'.)

Thus I think we should use double quotes (") to enclose the title instead of backticks. This seems to work (at least in my little test).

No, backticks ` are different from single quotes ' . Notice the backticks are a little skewed, like the Tower of Pisa (lol).

Urxae · « **Reply #15 on:** December 02, 2005, 04:30:46 pm »

Quote from: mandrav on December 02, 2005, 03:44:08 pm

Quote from: Urxae on December 02, 2005, 03:31:25 pm
Judging by the redirection, I presume it now also sends the build outpout to stdout? If so, you forgot to mention this.

Yes, I thought it was evident by the example

Just thought I'd clarify as Rick asked about it earlier in the thread and others might be interested as well.

Der Meister · « **Reply #16 on:** December 02, 2005, 04:45:33 pm »

Quote from: rickg22 on December 02, 2005, 04:15:01 pm

No, backticks ` are different from single quotes ' . Notice the backticks are a little skewed, like the Tower of Pisa (lol).

Argh.... Of course, you are right.

Seems as I got confused by a comment in the source code:

Quote

#ifndef __WXMSW__
// run the command in a shell, so backtick'd expressions can be evaluated
cmd->command = GetConsoleShell() + _T(" '") + cmd->command + _T("'");
#endif

Anyway, this doens't change the problem.

Urxae · « **Reply #17 on:** December 02, 2005, 06:04:20 pm »

I just compiled and updated from revision 1425, and then performed the following command from my C::B dir:

Code

output\codeblocks --personality=Build --hidden --build CodeBlocks-NewBuild.cbp | tee build.log

and the C::B window still showed itself, which I was assuming the --hidden parameter would prevent.
Did I misinterpret the intended meaning of this parameter?

mandrav · « **Reply #18 on:** December 03, 2005, 12:25:32 pm »

Quote from: Urxae on December 02, 2005, 06:04:20 pm

I just compiled and updated from revision 1425, and then performed the following command from my C::B dir:
Code
output\codeblocks --personality=Build --hidden --build CodeBlocks-NewBuild.cbp | tee build.log
and the C::B window still showed itself, which I was assuming the --hidden parameter would prevent.
Did I misinterpret the intended meaning of this parameter?

Nope, you just found a "bug".
It has to do with the automatic layout loading, which shows the window no matter if the --hidden flag says "don't"...
I 've located the problem and fixed it just now.

Also, note that the --hidden parameter is removed. It 's not needed because, for batch builds, the window is not responsive anyway. So now it's implicitely hidden for batch builds.

takeshimiya · « **Reply #19 on:** December 03, 2005, 02:18:03 pm »

I found this link very handy to know the latest changes, though it's more comfortable the TortoiseSVN's Show Log.

killerbot · « **Reply #20 on:** December 19, 2005, 10:53:43 pm »

Be aware that on the first runs you can get prompted to specify global vars values !!

Does it send build errors to stdout ot every build output, just tried this out, and nothing appeared on my console (windows xp).

killerbot · « **Reply #21 on:** December 19, 2005, 11:02:53 pm »

Also the command line invokation immediately returns, so in a batch list; the next instance will be started of CB-batch.
Hope this is multi-instance safe enough ?

280Z28 · « **Reply #22 on:** December 20, 2005, 01:10:01 am »

An easy thing to add that's extremely useful [to me] is simple actions for the mouse. Back and forward buttons, mouse wheel, plus modifier keys (ctrl, alt, shift, or combination) on all 5 standard mouse buttons (left, right, middle=wheelclick, back, forward) and the wheel (wheelup, wheeldown).

News:

Author Topic: Today's updates: 30 Nov 2005 (Read 20815 times)

takeshimiya

takeshimiya

takeshimiya