Author Topic: batchbuild issues with backticked commands (Read 28178 times)

tiwag · « **on:** October 18, 2006, 07:27:12 pm »

since rev 3103 my CB hangs infinite when trying to do a batchbuild started from the explorer's right-click popupmenu.

any ideas and or procedures how to catch the reason for this ?

brgds, tiwag

WinXP, wxMSW263p2

edit: changed thread title, as we know now what is the reason ...

killerbot · « **Reply #1 on:** October 18, 2006, 07:54:42 pm »

seems so strange rev 3103 could be the guilty one, that ere changes on the console runner, what was the mast version you tried where i worked ?

MortenMacFly · « **Reply #2 on:** October 18, 2006, 07:58:11 pm »

Quote from: tiwag on October 18, 2006, 07:27:12 pm

since rev 3103 my CB hangs infinite when trying to do a batchbuild started from the explorer's right-click popupmenu.

Works for me, batch-build and batch-re-build of a project from explorer (WinXP, wx263 but revision 3104...)?!
Did you try a full re-build and clearing the devel directory before? (There were quite some SDK changes...)
With regards, Morten.

tiwag · « **Reply #3 on:** October 18, 2006, 08:00:45 pm »

yes i've rebuilt it

normal build works fine, batchbuild hangs inf.

i'm out of ideas

killerbot · « **Reply #4 on:** October 18, 2006, 08:02:20 pm »

done a batch build and rebuild of a hello world console program --> both OK

tiwag · « **Reply #5 on:** October 18, 2006, 08:06:01 pm »

ok thanks for the info,

i stepped back to the last build where batchbuild worked for me, and it doesn't work anymore too,
so i have to investigate fiurther

... stay tuned

mandrav · « **Reply #6 on:** October 18, 2006, 08:19:34 pm »

Quote from: tiwag on October 18, 2006, 08:00:45 pm

yes i've rebuilt it

normal build works fine, batchbuild hangs inf.

i'm out of ideas

Have you tried to run C::B in the batch-build profile but *not* for batch-building?
Lots of changes lately and maybe the conf file needs to be updated by running the app once in that profile..? (just guessing because it works here too)

tiwag · « **Reply #7 on:** October 18, 2006, 08:25:42 pm »

Quote from: mandrav on October 18, 2006, 08:19:34 pm

Have you tried to run C::B in the batch-build profile but *not* for batch-building?

yes that was the first thing i did, there it runs fine and i can build/rebuild everything ...

i tried also to debug the devel-CB with running with --build any.cbp
but it hangs somewhere and doesn't crash

btw. i use a batchbuild profile, where all plugins but compiler are disabled,

brgds, tiwag

MortenMacFly · « **Reply #8 on:** October 18, 2006, 08:38:31 pm »

Quote from: tiwag on October 18, 2006, 08:25:42 pm

btw. i use a batchbuild profile, where all plugins but compiler are disabled,

A wild guess: Could you try what happens if you just re-enable the 3 wxSmith plugins in addition to the compiler plugin in this profile? (Because they onces caused trouble when disabling them using the new plugin framework).
With regards, Morten.

tiwag · « **Reply #9 on:** October 18, 2006, 08:58:44 pm »

Quote from: MortenMacFly on October 18, 2006, 08:38:31 pm

Quote from: tiwag on October 18, 2006, 08:25:42 pm
btw. i use a batchbuild profile, where all plugins but compiler are disabled,
A wild guess: Could you try what happens if you just re-enable the 3 wxSmith plugins in addition to the compiler plugin in this profile? (Because they onces caused trouble when disabling them using the new plugin framework).
With regards, Morten.

this didn't help anything

at the moment i've enabled compiler and environmentvariables plugins.

after a fresh svn checkout and build it was hanging too.

afterwards i renamed the config file and started from the roots ...
now it's working again.

something in the config file got screwed ...
don't know why and what

i'm happy, that it's working again

thanks to all for helping me
brgds, tiwag

tiwag · « **Reply #10 on:** October 18, 2006, 09:13:43 pm »

my previous post was way too fast ...

i found the reason for the hang

when i try to batch-build a project, which uses backticked `wx-config --cxxflags`
then it hangs infinitely with 100% cpu load. this project builds fine when i build it from the IDE

batch-building projects which are using custom variables is working fine.

attached is the project where it hangs for me.

brgds, tiwag

[attachment deleted by admin]

MortenMacFly · « **Reply #11 on:** October 18, 2006, 09:25:39 pm »

Quote from: tiwag on October 18, 2006, 09:13:43 pm

attached is the project where it hangs for me.

This works well for me (no hang). But: I don't have wx-config so this might be the reason...?!
(Will try and edit this post once I did this...)
With regards, Morten.

Edit: Agreed, with wx-config (D/L'ded from http://wxconfig.googlepages.com/) my C::B freezes, too. Anyway: This seems to be related to wx-config. When you replace the backtick'd command with something else (I did a "ls -lisa" ;-)) with works... allthough it doesn't compile, of course.

Edit2: To make it very clear: Yes, I know that "ls" is a linux command - but no, I am on Windows and just using the GnuWin32 tools... ;-)

tiwag · « **Reply #12 on:** October 18, 2006, 09:28:15 pm »

Quote from: MortenMacFly on October 18, 2006, 09:25:39 pm

Quote from: tiwag on October 18, 2006, 09:13:43 pm
attached is the project where it hangs for me.
This works well for me (no hang). But: I don't have wx-config so this might be the reason...?!
(Will try and edit this post once I did this...)
With regards, Morten.

i don't understand how you could build this project successfully, when you don't have wx-config ?? :shock:
I'm doing something wrong here

thanks, tiwag

MortenMacFly · « **Reply #13 on:** October 18, 2006, 09:31:35 pm »

Quote from: tiwag on October 18, 2006, 09:28:15 pm

i don't understand how you could build this project successfully, when you don't have wx-config ?? :shock:
I'm doing something wrong here

No, I couldn't build... I forgot to mention that (did it in the other post now - including the "results").
With regards, Morten.

tiwag · « **Reply #14 on:** October 18, 2006, 09:39:39 pm »

Quote from: MortenMacFly on October 18, 2006, 09:25:39 pm

Agreed, with wx-config (D/L'ded from http://wxconfig.googlepages.com/) my C::B freezes, too. Anyway: This seems to be related to wx-config...

but it doesn't explain, why it freezes CB only when batch-building ?!

wx-config doesn't freeze CB when you build a project normally from the IDE ?!

strange... i'm curious

Morten, many thanks for verifying this issue !!
brgds, tiwag

takeshimiya · « **Reply #15 on:** October 18, 2006, 09:46:42 pm »

Sorry to ruin the party, I'm at Rev. 3086 and here it builds fine both from the IDE and from Build from explorer, using same wx-config exe from http://wxconfig.googlepages.com/) .

HOWEVER, I must note something is wrong with C::B file associations: when I do a double click on any CBP I get a Windows cannot find 'path\to\file.cbp'...

Something strange?

Log I get when I use batch builds:
-------------- Build: Release-wxdll in autobuildnumber --------------- mingw32-g++.exe -fexpensive-optimizations -Os -Wall -mthreads -DHAVE_W32API_H -D__WXMSW__ -ID:\Develop\src\wxWidgets-2.6.3\lib\gcc_dll\msw -ID:\Develop\src\wxWidgets-2.6.3\include -DWXUSINGDLL -Wno-ctor-dtor-privacy -pipe -fmessage-length=0 -ID:\Develop\bin\mingw345\include -ID:\Develop\MyPaks\include -ID:\Develop\DevPaks\include -ID:\cbbb\ -c autobuildnumber.cpp -o .objs\autobuildnumber.o mingw32-g++.exe -LD:\Develop\bin\mingw345\lib -LD:\Develop\MyPaks\lib -LD:\Develop\DevPaks\lib -o autobuildnumber.exe .objs\autobuildnumber.o -s -mthreads -LD:\Develop\src\wxWidgets-2.6.3\lib\gcc_dll -lwxmsw26 -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregex -lwxexpat -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwxregex -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 autobuildnumber.cpp: In function `void IncrementVersion(const wxString&, wxString*, const wxString&)': autobuildnumber.cpp:286: warning: int format, long int arg (arg 2) Process terminated with status 0 (0 minutes, 5 seconds) 0 errors, 1 warnings

Log when I use the IDE:
-------------- Build: Release-wxdll in autobuildnumber --------------- mingw32-g++.exe -fexpensive-optimizations -Os -Wall -mthreads -DHAVE_W32API_H -D__WXMSW__ -D_UNICODE -ID:\Develop\src\wxWidgets-2.6.3\lib\gcc_dll\mswu -ID:\Develop\src\wxWidgets-2.6.3\include -DWXUSINGDLL -Wno-ctor-dtor-privacy -pipe -fmessage-length=0 -ID:\Develop\bin\mingw345\include -ID:\Develop\MyPaks\include -ID:\Develop\DevPaks\include -ID:\cbbb\ -c autobuildnumber.cpp -o .objs\autobuildnumber.o mingw32-g++.exe -LD:\Develop\bin\mingw345\lib -LD:\Develop\MyPaks\lib -LD:\Develop\DevPaks\lib -o autobuildnumber.exe .objs\autobuildnumber.o -s -mthreads -LD:\Develop\src\wxWidgets-2.6.3\lib\gcc_dll -lwxmsw26u -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwxregexu -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 Process terminated with status 0 (0 minutes, 5 seconds) 0 errors, 0 warnings

EDIT: if this is a bug and was introduced in some rev. between 3086~3105, then at a first glance 3099 or 3094 seems the most likely.

tiwag · « **Reply #16 on:** October 18, 2006, 09:57:41 pm »

i found the reason

the problem is, that wx-config doesn't return anything to stdout, when it errors out,
this obviously confuses the backticked-command expander

the reason, why it behaves different when using from the IDE or from batchbuild
is obviously located in the environment variables plugin.

normally i don't have an environment variable WXWIN defined,
but i defined it to a valid value in the environmentvariables plugin,
which works fine with wx-config when using from the ide

defined in environment variables: WXWIN=D:\wx263
`wx-config --cxxflags` expands fine to shared ansi release wx-library

when batchbuilding the same project, CB hangs because `wx-config --cxxflags` doesn't return anything

evidence:
when using `wx-config --prefix=d:\wx263 --cxxflags` instead, then the project builds fine from the IDE and
from batch-build.

conclusion:
wx-config should return at least an error message if it couldn't find the requested wx-library
CB should check if there was any character returned and handle the case if no chars are coming instead of hanging around lazy

CB environment variables plugin should also work in batch-build mode !!!!

brgds, tiwag

MortenMacFly · « **Reply #17 on:** October 18, 2006, 09:59:29 pm »

Quote from: tiwag on October 18, 2006, 09:39:39 pm

but it doesn't explain, why it freezes CB only when batch-building ?!
wx-config doesn't freeze CB when you build a project normally from the IDE ?!

No, actually this I didn't try - until now. The project I used for testing previously did not use wx-config.
So yes: Using wx-config also freezes C::B in non-batch-build-mode, but only if using wx-config. Any other tools I enter just works fine (but of course causes a compilation error).
@Takeshi: Could you try another C::B with a higher revision, please? Maybe we can narrow down when this happened - so obvioulsy between 3086 and 3003... or what?! ;-)
With regards, Morten.

tiwag · « **Reply #18 on:** October 18, 2006, 10:02:44 pm »

Quote from: MortenMacFly on October 18, 2006, 09:59:29 pm

...Any other tools I enter just works fine (but of course causes a compilation error)...

try any other tool which doesn't return anything to stdout

MortenMacFly · « **Reply #19 on:** October 18, 2006, 10:04:36 pm »

Quote from: tiwag on October 18, 2006, 09:57:41 pm

conclusion:
wx-config should return at least an error message if it couldn't find the requested wx-library
CB should check if there was any character returned and handle the case if no chars are coming instead of hanging around lazy
CB environment variables plugin should also work in batch-build mode !!!!

Our posts have crossed - sorry for that. But what I don't get: I don't have a WXWIN variable defined in the envvar plugin thus if I use wx-config it also freezes the IDE during non-batch-build-mode build. Did you say it doesn't freezes your IDE in non-batch-build-mode? Could you try what happens if you remove the WXWIN envvar and try to compile this project from the IDE (in non-batch-build-mode)?
With regards, Morten.

Ps.: You said previously that you've disabled all plugins for the batch-build. How should the envvar plugin work then?!

takeshimiya · « **Reply #20 on:** October 18, 2006, 10:09:32 pm »

Quote from: tiwag on October 18, 2006, 09:57:41 pm

i found the reason

the problem is, that wx-config doesn't return anything to stdout, when it errors out,
this obviously confuses the backticked-command expander

Have you tested that from the command line? wx-config output this if you call wx-config --cxxflags:

*** Error: wxWidgets hasn't been found installed at 'C:\wxWidgets'. Please use the --prefix flag (as in `wx-config --prefix=C:\wxWidgets`) or set the environment variable WXWIN (as in WXWIN=C:\wxWidgets) to specify where is your installation of wxWidgets.

Side note: I don't know if it's better to output those errors to std:cerr instead of std::cout.

Quote from: tiwag on October 18, 2006, 09:57:41 pm

the reason, why it behaves different when using from the IDE or from batchbuild
is obviously located in the environment variables plugin.

Another side note: Don't you think environment variables should become part of the SDK? I happen to want to use it on plugins and wizards.

Quote from: tiwag on October 18, 2006, 09:57:41 pm

normally i don't have an environment variable WXWIN defined,
but i defined it to a valid value in the environmentvariables plugin,
which works fine with wx-config when using from the ide

Well, I can confirm that unsetting WXWIN, etc definitely hangs C::B, but it should be because wx-config outputs the "message garbage Error: wxWidgets hasn't been found installed...", not because it doesn't outputs anything.

Quote from: tiwag on October 18, 2006, 09:57:41 pm

CB environment variables plugin should also work in batch-build mode !!!!

SDK

tiwag · « **Reply #21 on:** October 18, 2006, 10:12:48 pm »

Quote from: MortenMacFly on October 18, 2006, 10:04:36 pm

Quote from: tiwag on October 18, 2006, 09:57:41 pm
conclusion:
wx-config should return at least an error message if it couldn't find the requested wx-library
CB should check if there was any character returned and handle the case if no chars are coming instead of hanging around lazy
CB environment variables plugin should also work in batch-build mode !!!!
Our posts have crossed - sorry for that. But what I don't get: I don't have a WXWIN variable defined in the envvar plugin thus if I use wx-config it also freezes the IDE during non-batch-build-mode build. Did you say it doesn't freezes your IDE in non-batch-build-mode? Could you try what happens if you remove the WXWIN envvar and try to compile this project from the IDE (in non-batch-build-mode)?
With regards, Morten.

Ps.: You said previously that you've disabled all plugins for the batch-build. How should the envvar plugin work then?!

the compiler and environmentvariables plugins are enabled, and it works from the ide,
and yes, it does freeze CB when building from the ide, when i disable the WXWIN environment variable.

we have shot the problem !

btw. i tested a program, which return nothing, and this DOES NOT FREEZE CB !!!
my previous assumption was wrong !

but also wx-config is no longer running, when CB freezes

tiwag · « **Reply #22 on:** October 18, 2006, 10:14:07 pm »

Quote from: Takeshi Miya on October 18, 2006, 10:09:32 pm

Quote from: tiwag on October 18, 2006, 09:57:41 pm
i found the reason

the problem is, that wx-config doesn't return anything to stdout, when it errors out,
this obviously confuses the backticked-command expander

Have you tested that from the command line? wx-config output this if you call wx-config --cxxflags:

*** Error: wxWidgets hasn't been found installed at 'C:\wxWidgets'. Please use the --prefix flag (as in `wx-config --prefix=C:\wxWidgets`) or set the environment variable WXWIN (as in WXWIN=C:\wxWidgets) to specify where is your installation of wxWidgets.

Side note: I don't know if it's better to output those errors to std:cerr instead of std::cout.

Quote from: tiwag on October 18, 2006, 09:57:41 pm
the reason, why it behaves different when using from the IDE or from batchbuild
is obviously located in the environment variables plugin.
Another side note: Don't you think environment variables should become part of the SDK? I happen to want to use it on plugins and wizards.

Quote from: tiwag on October 18, 2006, 09:57:41 pm
normally i don't have an environment variable WXWIN defined,
but i defined it to a valid value in the environmentvariables plugin,
which works fine with wx-config when using from the ide
Well, I can confirm that unsetting WXWIN, etc definitely hangs C::B, but it should be because wx-config outputs the "message garbage Error: wxWidgets hasn't been found installed...", not because it doesn't outputs anything.

Quote from: tiwag on October 18, 2006, 09:57:41 pm
CB environment variables plugin should also work in batch-build mode !!!!
SDK

i guess this goes to stderr and not to stdout !

try

wx-config --leckmich > wx-config.log

what do you see in the log file ? nothing !

takeshimiya · « **Reply #23 on:** October 18, 2006, 10:18:16 pm »

Quote from: tiwag on October 18, 2006, 10:14:07 pm

wx-config --leckmich > wx-config.log

what do you see in the log file ? nothing !

*** Error: Unrecognised option: '--leckmich' Usage: wx-config [options] Options: --prefix[=DIR] Path of the wxWidgets installation (ie. C:\wxWidgets2.6.3) --wxcfg[=DIR] Relative path of the build.cfg file (ie. gcc_dll\mswud) --cflags Outputs all pre-processor and compiler flags. --cxxflags Same as --cflags but for C++. --rcflags Outputs all resource compiler flags. [UNTESTED] --libs Outputs all linker flags. --debug[=yes|no] Uses a debug configuration if found. --unicode[=yes|no] Uses an unicode configuration if found. --static[=yes|no] Uses a static configuration if found. --universal[=yes|no] Uses an universal configuration if found. --easymode[=yes|no] Outputs warnings, and optimize flags. --compiler[=gcc,dmc,vc] Selects the compiler. --release Outputs the wxWidgets release number. --cc Outputs the name of the C compiler. --cxx Outputs the name of the C++ compiler. --ld Outputs the linker command. -v Outputs the revision of wx-config. Note that using --prefix is not needed if you have defined the environmental variable WXWIN. Also note that using --wxcfg is not needed if you have defined the environmental variable WXCFG.

:?

But anyways I get the C::B crash from the IDE.

tiwag · « **Reply #24 on:** October 18, 2006, 10:33:58 pm »

maybe a buffer overflow in CB ?

MortenMacFly · « **Reply #25 on:** October 18, 2006, 10:43:44 pm »

Quote from: tiwag on October 18, 2006, 10:14:07 pm

wx-config --leckmich > wx-config.log

I couldn't resist: lol :lol:

Quote from: tiwag on October 18, 2006, 10:33:58 pm

maybe a buffer overflow in CB ?

But I don't see what could have caused this in the changes between those revisions we have identified...?!

tiwag · « **Reply #26 on:** October 18, 2006, 10:51:37 pm »

Quote from: MortenMacFly on October 18, 2006, 10:43:44 pm

Quote from: tiwag on October 18, 2006, 10:33:58 pm
maybe a buffer overflow in CB ?
But I don't see what could have caused this in the changes between those revisions we have identified...?!

i know the reason :

the output from the error message is:

>wx-config --prefix=d:\x263 --cxxflags

*** Error: wxWidgets hasn't been found installed at 'd:\x263'. Please use the --prefix flag (as in `wx-config --prefix=C:\wxWidgets`) or set the environment variable WXWIN (as in WXWIN=C:\wxWidgets) to specify where is your installation of wxWidgets.

this makes an infinite loop !

takeshimiya · « **Reply #27 on:** October 18, 2006, 10:58:18 pm »

I've narrowed it down to calling

Quote

wx-config --prefix=

from command line. It hangs.

So it seems that when wx-config hangs it hangs C::B too.
Anyways the exe was built with MSVC 2005 Express and I can't debug it. :?

But when built with GCC or DMC it doesn't hangs and everything seems normal.

So in the meantime I've uploaded one built with DMC:
http://wx-config-win.googlecode.com/svn/binary/wx-config.exe

tiwag · « **Reply #28 on:** October 18, 2006, 11:00:39 pm »

i tried the following :

Code

//nix.cpp -> nix.exe

#include <iostream>

int main(){
   std::string s1 = "`nix` ;-)";
   std::cout << s1 << std::endl;
   return 0;
}

and use this as backticked command `nix` to the compiler options

result, CB hangs because it recursively tries to resolve `nix`

conclusion:
1.) wx-config MUST return an error message WITHOUT a self-referencing backticked command !!!
2.) the CB environmentvariables plugin doesn't work in batchbuild mode or isn't initialized at the time,
when the compiler starts resolving backticked commands

brgds, tiwag

tiwag · « **Reply #29 on:** October 18, 2006, 11:03:43 pm »

Quote from: Takeshi Miya on October 18, 2006, 10:58:18 pm

I've narrowed it down to calling
Quote
wx-config --prefix=
from command line. It hangs.

So it seems that when wx-config hangs it hangs C::B too.
Anyways the exe was built with MSVC 2005 Express and I can't debug it. :?

But when built with GCC or DMC it doesn't hangs and everything seems normal.

So in the meantime I've uploaded one built with DMC:
http://wx-config-win.googlecode.com/svn/binary/wx-config.exe

wx-config doesn't hang, it is called infinitely !
see other post using `nix`

MortenMacFly · « **Reply #30 on:** October 18, 2006, 11:12:17 pm »

Finally! The solution. Good work, tiwag - I guess we can go to bed then, right?! ;-)

Quote from: tiwag on October 18, 2006, 11:00:39 pm

2.) the CB environmentvariables plugin doesn't work in batchbuild mode or isn't initialized at the time,
when the compiler starts resolving backticked commands

I guess this is on my desk, then... will look into it... but not today.
With regards, Morten.

tiwag · « **Reply #31 on:** October 18, 2006, 11:14:37 pm »

Quote from: MortenMacFly on October 18, 2006, 11:12:17 pm

Finally! The solution. Good work, tiwag - I guess we can go to bed then, right?! ;-)

you can go to bed, i go for a couple of beers now

seriously
thank you too !

best regards, tiwag

takeshimiya · « **Reply #32 on:** October 18, 2006, 11:18:09 pm »

Ok, so we've found pretty different issues, listing:

1) wx-config --prefix= hangs even in command-line when the exe was built with MSVC2005 Express only.
2) Code::Blocks parses backticks outputs. Thus self-referencing backticks causes an infinite loop. Is this good behaviour or not?
3) The Environment Variables should be part of the SDK, if not, we have inter-plugin dependences and the side effect that you get different things between batch builds and normal builds.
4) Question: for those who know, errors should be better printed in stdout or stderr? My idea is that a C::B regex can parse them.
5) DDE bug attacking again Windows cannot find 'file.cbp'....
6) The default.conf is getting unreliable lately, but this is for another post.

I have "fixed" 1), and can workaround 2) simply don't printing self-referencing backticks, however, is that good behaviour?

MortenMacFly · « **Reply #33 on:** October 18, 2006, 11:24:00 pm »

Quote from: Takeshi Miya on October 18, 2006, 11:18:09 pm

3) The Environment Variables should be part of the SDK, if not, we have inter-plugin dependences and the side effect that you get different things between batch builds and normal builds.

I wouldn't say this. It can (and should) be a plugin (otherwise you could argue that e.g. the compiler plugin should be in the sdk, too - right?). The only issue here is that obviously the OnAttach() method seems not to be called on a batch-build process for an obscure reason... will investigate in this...
With regards, Morten.

Edit: What takeshi might fail to se: Once the envvar plugin got initialised correctly you'll get all envvars through macromanager anymway. Thus they are abailable for e.g. scripting and stuff... (Or maybe I don't understand why he states this...?!)

tiwag · « **Reply #34 on:** October 18, 2006, 11:30:33 pm »

some comments

Quote from: Takeshi Miya on October 18, 2006, 11:18:09 pm

1) wx-config --prefix= hangs even in command-line when the exe was built with MSVC2005 Express only.

~~didn't try but i don't believe this~~
edit: i've build my wx-config using gcc

:shock:

Quote from: Takeshi Miya on October 18, 2006, 11:18:09 pm

2) Code::Blocks parses backticks outputs. Thus self-referencing backticks causes an infinite loop. Is this good behaviour or not?

it is good behavior

think of nested calls of some backticked commands

`aaa` -> `bbb` -> "something useful"

Quote from: Takeshi Miya on October 18, 2006, 11:18:09 pm

3) The Environment Variables should be part of the SDK, if not, we have inter-plugin dependences and the side effect that you get different things between batch builds and normal builds.

i'm shure, Morten will find a reliable solution for this ...

Quote from: Takeshi Miya on October 18, 2006, 11:18:09 pm

4) Question: for those who know, errors should be better printed in stdout or stderr? My idea is that a C::B regex can parse them.

PLEASE don't print novels as error messages

just send ( "ERROR: %d : %s\n", errornumber , errordescription )

send your novels to stderr, if you can't resist ;-)

Quote from: Takeshi Miya on October 18, 2006, 11:18:09 pm

5) DDE bug attacking again Windows cannot find 'file.cbp'....

delete all dde related registry keys from CodeBlocks registered file extensions ( ".cbp" and so on )

Quote from: Takeshi Miya on October 18, 2006, 11:18:09 pm

6) The default.conf is getting unreliable lately, but this is for another post.

true, i had a lot of issues too

brds, tiwag

takeshimiya · « **Reply #35 on:** October 18, 2006, 11:35:12 pm »

Quote from: MortenMacFly on October 18, 2006, 11:24:00 pm

Quote from: Takeshi Miya on October 18, 2006, 11:18:09 pm
3) The Environment Variables should be part of the SDK, if not, we have inter-plugin dependences and the side effect that you get different things between batch builds and normal builds.
I wouldn't say this. It can (and should) be a plugin (otherwise you could argue that e.g. the compiler plugin should be in the sdk, too - right?).

Yes, both ways are arguable, but because you could say "have cbEditor as plugin", or for example you can "set the Network proxy" in Environment, but you can't "set environment variables"?
Either way, it's fine as long while it can be accessed from Squirrel.

MortenMacFly · « **Reply #36 on:** October 18, 2006, 11:35:54 pm »

Quote from: tiwag on October 18, 2006, 11:30:33 pm

Quote from: Takeshi Miya on October 18, 2006, 11:18:09 pm
6) The default.conf is getting unreliable lately, but this is for another post.
true, i had a lot of issues too

I think this has already been resolved by Thomas meanwhile. IMHO the reason were the TinyXml changes related to <, > and consorts. But this works now properly... (I hadn't have any issues since then).
With regards, Morten.

MortenMacFly · « **Reply #37 on:** October 18, 2006, 11:37:37 pm »

Quote from: Takeshi Miya on October 18, 2006, 11:35:12 pm

Either way, it's fine as long while it can be accessed from Squirrel.

So hopefully you've seen that I have edited the post you are refering to meanwhile (sorry if our posts crossed). So this should be fine then?!
With regards, Morten.

takeshimiya · « **Reply #38 on:** October 18, 2006, 11:45:00 pm »

Quote from: tiwag on October 18, 2006, 11:30:33 pm

Quote from: Takeshi Miya on October 18, 2006, 11:18:09 pm
1) wx-config --prefix= hangs even in command-line when the exe was built with MSVC2005 Express only.
didn't try but i don't believe this

Then try it first :wink:
You may have to do a

Quote

set WXCFG=

and

Quote

set WXWIN=

to reproduce it.

Quote from: tiwag on October 18, 2006, 11:30:33 pm

Quote from: Takeshi Miya on October 18, 2006, 11:18:09 pm
2) Code::Blocks parses backticks outputs. Thus self-referencing backticks causes an infinite loop. Is this good behaviour or not?
it is good behavior

think of nested calls of some backticked commands

`aaa` -> `bbb` -> "something useful"

OK, re-asking the question and having in mind that back-ticks in Windows are supposed to do exactly the same thing as in Linux.
So the question becomes: what does bash with self-referencing back-ticks? We need to have the same behavior.

Quote from: Takeshi Miya on October 18, 2006, 11:18:09 pm

4) Question: for those who know, errors should be better printed in stdout or stderr? My idea is that a C::B regex can parse them.

Quote from: tiwag on October 18, 2006, 11:30:33 pm

PLEASE don't print novels as error messages

just send ( "ERROR: %d : %s\n", errornumber , errordescription )

In short, sending long messages to stderr and one-liners to stdout is what you suggest and what gcc does, for instance?

takeshimiya · « **Reply #39 on:** October 18, 2006, 11:48:38 pm »

Quote from: MortenMacFly on October 18, 2006, 11:35:54 pm

I think this has already been resolved by Thomas meanwhile. IMHO the reason were the TinyXml changes related to <, > and consorts. But this works now properly... (I hadn't have any issues since then).
With regards, Morten.

Yes, but I'm talking about lot of different issues with it not related to that, which deserves a thread on it's own.

Quote from: MortenMacFly on October 18, 2006, 11:37:37 pm

So hopefully you've seen that I have edited the post you are refering to meanwhile (sorry if our posts crossed). So this should be fine then?!

If one can Add new variables, Change variable values, Delete variables, Toggle variables and Set now variables from Squirrel, it's perfectly fine.

tiwag · « **Reply #40 on:** October 19, 2006, 12:22:01 am »

Quote from: Takeshi Miya on October 18, 2006, 11:45:00 pm

In short, sending long messages to stderr and one-liners to stdout is what you suggest and what gcc does, for instance?

yes

maybe just "wx-config ERROR: 01 : error description ..." to stdout, this will then be seen in the buildlog,
the long text to stderr

you can test, what wx-config does on linux ?

brgds, tiwag

tiwag · « **Reply #41 on:** October 19, 2006, 12:29:02 am »

thread title changed, batchbuild isn't broken

mandrav · « **Reply #42 on:** October 19, 2006, 10:28:46 am »

Regarding the envvars plugin, rev.3109 contains the fix.
As part of an optimization implemented some time ago, only the compiler plugin was allowed to load in batch-build mode. Rev.3109 adds control over this by adding a checklist of plugins to load in batch build options (Settings->Compiler&debugger->Batch builds). This is the master list for batch-build mode, i.e. for a plugin to be loaded in this mode it must be checked in that list and enabled in the plugin management dialog.
Defaults to only loading the compiler plugin.

As you can understand, it is no longer necessary to even create a separate profile/personality for batch builds, since usually you create a different profile only to disable most of the plugins

.

I haven't tested this so if you can test it you 'd be doing me a favour

.

tiwag · « **Reply #43 on:** October 19, 2006, 02:54:03 pm »

Quote from: mandrav on October 19, 2006, 10:28:46 am

I haven't tested this so if you can test it you 'd be doing me a favour .

it's working fine, thanks !

Quote from: mandrav on October 19, 2006, 10:28:46 am

As you can understand, it is no longer necessary to even create a separate profile/personality for batch builds, since usually you create a different profile only to disable most of the plugins

in general you are right, but it's not entirely true,
my differences (beside the plugins) betweeen development and batch-build profiles are additionally

devel batchbuild compiler logging full short dual monitor setup main screen secondary screen

brgds, tiwag

takeshimiya · « **Reply #44 on:** October 19, 2006, 10:47:13 pm »

Quote from: tiwag on October 19, 2006, 12:22:01 am

maybe just "wx-config ERROR: 01 : error description ..." to stdout, this will then be seen in the buildlog,
the long text to stderr

Fixed all in Rev.21

* Removed all back-ticks characters from explanatory messages to prevent self-referencing back-ticks.
* Now explanatory messages are printed to stderr and one-line message errors are printed to stdout
with the format "wx-config Error: description".

News:

Author Topic: batchbuild issues with backticked commands (Read 28178 times)

takeshimiya

takeshimiya

takeshimiya

takeshimiya

takeshimiya

takeshimiya

takeshimiya

takeshimiya

takeshimiya