|
|
ABLD.BAT exit code
| Wed, 2008-01-30 10:40 | |
|
Hi, I am setting up an automated build environment for the S60 3rd SDK. The software runnig the build is a modified version of Bitten, part of the Trac project. Everything works fine till one wants to get the status of the last build. As usual - I am expecting that abld would return an adequate exit code so one would know that build is OK or something went wrong with the it. Unfortunately abld's exit code is always 0 meaning - for me and any wrapping software - that the last command succeeded. It is 0 even when gcc or make break and exit with non zero error code. Build stops but the error code does not propagate through the build chain and I get the 0 again. This issue is important even when developing on Carbide.C++ - especially v1.2 - where console build does the whole job and one always gets Build Complete message. If the build output parser does not detect an error - user would not even bother to check "manually" if there are errors in the output. Such errors are very annoying and slow down the development cycle a lot. Does anyone know a way to force abld return with the proper value in the operating system. thanks |
|
Forum posts: 49
ABLD is just .bat file which looks like this
@ECHO OFF
REM Bldmake-generated batch file - ABLD.BAT
REM ** DO NOT EDIT **
perl -S ABLD.PL "MyProject\group\\" %1 %2 %3 %4 %5 %6 %7 %8 %9
if errorlevel==1 goto CheckPerl
goto End
:CheckPerl
perl -v >NUL
if errorlevel==1 echo Is Perl, version 5.003_07 or later, installed?
goto End
:End
so maybe you should manually call this
perl -S ABLD.PL "MyProject\group\\" %1 %2 %3 %4 %5 %6 %7 %8 %9and check code returned by it.
Forum posts: 4
Thanks for the proposal.
I knew it was just a bat file and already tried that with no luck. Unfortunately bat files do not imply an incorrect exit value. On the contrary - the bat file should exit with the exit code of that same command running the abld.pl Perl script (with the single exception when it's exit code is 1 - not my case).
But the Perl build wrappers return 0 themselves. I've been diving into Symbian's Perl tool libs for some time and get more and more frustrated.
abld.bat is the "user's view" of the Symbian build system and it should be polished after so many years of history. So I thought there might be a SDK setting that tweaks the default behavior of the build system.
Looking inside the Perl script I can see no sign that anything like this happens. The only exit calls return either 0 or 1 (in the case of a Perl version mismatch). die calls do really exist bu no one sets the proper errno (exit value) so we end up with a crippled script that cannot tell us whether any command run by the system has failed.
In Carbide.c++ 1.3 some of the functionality of the perl wrappers has been taken over by the Java plug-ins.
Because I am aiming an automated build environment this is a noop. It would be much pain to automatically start Build from within Carbide, not to mention the unavailability of build status in that case either.
Any suggestions for such an environment?
Regards
Forum posts: 49
Other option is to grab output of ABLD command ( stdio + stderr ) on the fly and check if some errors/warrnings appears or not .
Forum posts: 4
Yes, that's what Carbide does.
Could give it a try. Doing that in python is not much of a work. Just wonder why this "feature" does not get fixed.
Thanks, Iman
Forum posts: 4
Success, yet this is an ugly hack for a good OS.
Do we all use only Carbide and a desktop PC for during software production cycle?
Alternatively - I succeeded in modifying the "Perl build system" so that a kind of continuous integration could take place.
The amount of Perl coding I had to experience is not one wants to get in the way when dealing with mobile. Nor is a ready made patch for a specific SDK. What comes around with the new SDK coming out? Another patch?
Has anyone had experience with another approach?
Forum posts: 1133
There is a lot of things needed to be fixed for a long time in the build environment imo...
no exit codes, path-problems (infamous no space allowed), drive problems (can only work if project and sdk is on same drive), bad error visibility, slowness (can take it minutes just to walk through all header files), just to name a few.
The complex and easy-to-break build environment is one of symbians weakest points imo.
And not that much one can do yourself, without getting stuck in a bog of patches and having to re-do everything each SDK release...
Please do tell if you find some good way to tackle this to create automated build environments...
It would be very useful for a lot of people I think.
I also think you probably will have to parse output for it though...
In my experience, it is almost only 3rd party developers that use Carbide.
The people at Symbian, S60, S-E, UIQ, and others doing lower level work on symbian, still use Metrowerks Codewarrior and the command line tools as their main environment.
Probably they will never drop support for the command line tools, unless they suddenly decide to rewrite it from scratch and make something easier to use for things like night builds and automated testing... Though unfortunately I don't think this is a high priority...