Helo:
good morning.

I have a great project file that must only compile the programs, without 
generating objects.
I inserted a flag /e:600 expecting it was all section long.
The PBuild stops after a few program errors.

Can one tell me why?

Beling
TIA

[PROJECT]
     COMPILE       = xpp
     COMPILE_FLAGS = /a /m /n /q /w /wu /s /err:600
     DEBUG         =
     GUI           = no
     LINKER        = alink
     LINK_FLAGS    =
     RC_COMPILE    = arc
     RC_FLAGS      = /v
     PBUILD        =
     MAKE          =
     PROJECT.XPJ

[PROJECT.XPJ]
     Compila.exe

[compila.EXE]
     AFASTA.PRG
     ATU000.PRG
...

Carlos Beling wrote:

> I have a great project file 

How many .prg files is "great" in your case?

> that must only compile the programs, without 
> generating objects.

Hmmm... the result of compilation is an object file... 

> I inserted a flag /e:600 expecting it was all section long.
> The PBuild stops after a few program errors.
> 
> Can one tell me why?

Without the whole project and without the error mesage, probably not...

regards
Thomas

Hi Thomas:
good afgternoon.
Here it is. It is used only for correcting errors and variables not used.
Many thanks.

Beling
Best regards

Thomas Braun escreveu:
> Carlos Beling wrote:
> 
>> I have a great project file 
> 
> How many .prg files is "great" in your case?
> 
>> that must only compile the programs, without 
>> generating objects.
> 
> Hmmm... the result of compilation is an object file... 
> 
>> I inserted a flag /e:600 expecting it was all section long.
>> The PBuild stops after a few program errors.
>>
>> Can one tell me why?
> 
> Without the whole project and without the error mesage, probably not...
> 
> regards
> Thomas

Carlos Beling wrote:

> Hi Thomas:
> good afgternoon.
> Here it is. It is used only for correcting errors and variables not used.

Hi Carlos, 

now I understand... had to look up the /s switch first as I never used it
before 

So the project compiles correct if there are no syntax errors and/or unused
variables?

I would say the project file is not very large, 100 program files should
not be that much. I can' tell you why this does not work.

Try to remove the /q switch to get more information or to see where it
stops.

regards
Thomas

HI Thomas;
good afternoon.
Many thanks.
The /s switch is very good only for debugging purpose (ie get non referenced 
variables).
Yes, the project compiles correct until find an error.
I'll try removing the /q switch, I think that, in despite it, the Pbuild would 
not stop.

Beling
Many thanks

Thomas Braun escreveu:
> Carlos Beling wrote:
> 
>> Hi Thomas:
>> good afgternoon.
>> Here it is. It is used only for correcting errors and variables not used.
> 
> Hi Carlos, 
> 
> now I understand... had to look up the /s switch first as I never used it
> before 
> 
> So the project compiles correct if there are no syntax errors and/or unused
> variables?
> 
> I would say the project file is not very large, 100 program files should
> not be that much. I can' tell you why this does not work.
> 
> Try to remove the /q switch to get more information or to see where it
> stops.
> 
> regards
> Thomas

Hello Thomas:
good afternoon.
I took off the switch /q and Pbuilder stopped. I hope that people of Alaska 
read this post because it seems really to be a problem   .

Beling
Best regards

Carlos Beling escreveu:
> HI Thomas;
> good afternoon.
> Many thanks.
> The /s switch is very good only for debugging purpose (ie get non 
> referenced variables).
> Yes, the project compiles correct until find an error.
> I'll try removing the /q switch, I think that, in despite it, the Pbuild 
> would not stop.
> 
> Beling
> Many thanks
> 
> Thomas Braun escreveu:
>> Carlos Beling wrote:
>>
>>> Hi Thomas:
>>> good afgternoon.
>>> Here it is. It is used only for correcting errors and variables not 
>>> used.
>>
>> Hi Carlos,
>> now I understand... had to look up the /s switch first as I never used it
>> before 
>>
>> So the project compiles correct if there are no syntax errors and/or 
>> unused
>> variables?
>>
>> I would say the project file is not very large, 100 program files should
>> not be that much. I can' tell you why this does not work.
>>
>> Try to remove the /q switch to get more information or to see where it
>> stops.
>>
>> regards
>> Thomas

Carlos Beling wrote:

> Hello Thomas:
> good afternoon.
> I took off the switch /q and Pbuilder stopped. I hope that people of Alaska 
> read this post because it seems really to be a problem   .

You really should contact Alaska support via email...

Thomas

Hello Thomas:
good morning.
Many thanks.
I'm doing it right now.

Beling
Best regards


Thomas Braun escreveu:
> Carlos Beling wrote:
> 
>> Hello Thomas:
>> good afternoon.
>> I took off the switch /q and Pbuilder stopped. I hope that people of Alaska 
>> read this post because it seems really to be a problem   .
> 
> You really should contact Alaska support via email...
> 
> Thomas

I can't find a /s switch for pbuild. There is one for xpp. So why would
you think that pbuild would not stop if errors where found in a prg????

The compiler /s simply stops the compiler from creating a OBJ file. it
does not stop it from reporting that it found errors and thus stopping
pbuild.

Jim

Carlos Beling wrote:
> Hello Thomas:
> good morning.
> Many thanks.
> I'm doing it right now.
> 
> Beling
> Best regards
> 
> 
> Thomas Braun escreveu:
>> Carlos Beling wrote:
>>
>>> Hello Thomas:
>>> good afternoon.
>>> I took off the switch /q and Pbuilder stopped. I hope that people of
>>> Alaska read this post because it seems really to be a problem   .
>>
>> You really should contact Alaska support via email...
>>
>> Thoma

Hi Jimmy:
good afternoon.


James Loughner escreveu:
> I can't find a /s switch for pbuild. There is one for xpp.
Really PBuild has not /s switch.
  So why would you think that pbuild would not stop if errors where found in a 
prg????
I can not understanding why it stops: it has a switch /Err:600 (used for each 
prg, not cumulative) and a switch for only compiling (/s). No job to do: only 
compile. Then why stopping at the first error found?  
> 
> The compiler /s simply stops the compiler from creating a OBJ file. it
> does not stop it from reporting that it found errors and thus stopping
> pbuild.
In this case is almost to ear: you first compile all programs, correct the 
errors and them build your project, is not it? rsrsrs

Many thanks again.

Beling
Best regards
> 
> Jim
> 
> Carlos Beling wrote:
>> Hello Thomas:
>> good morning.
>> Many thanks.
>> I'm doing it right now.
>>
>> Beling
>> Best regards
>>
>>
>> Thomas Braun escreveu:
>>> Carlos Beling wrote:
>>>
>>>> Hello Thomas:
>>>> good afternoon.
>>>> I took off the switch /q and Pbuilder stopped. I hope that people of
>>>> Alaska read this post because it seems really to be a problem   .
>>> You really should contact Alaska support via email...
>>>
>>> Thoma

Hello:
good morning.
I think that Pbuild has a bug: I used in the project (attached) the switch /s 
  only for debugging purpose and Pbuild is stopping when an error occurs. I 
think it might not stops because I'm only checking.
Please see also the Stopped.jpg attached.

Beling
Best regards

Hi Thomas:
good afgternoon.
Here it is. It is used only for correcting errors and variables not used.
Many thanks.

Beling
Best regards

Thomas Braun escreveu:
> Carlos Beling wrote:
> 
>> I have a great project file 
> 
> How many .prg files is "great" in your case?
> 
>> that must only compile the programs, without 
>> generating objects.
> 
> Hmmm... the result of compilation is an object file... 
> 
>> I inserted a flag /e:600 expecting it was all section long.
>> The PBuild stops after a few program errors.
>>
>> Can one tell me why?
> 
> Without the whole project and without the error mesage, probably not...
> 
> regards
> Thomas

Carlos,

>The PBuild stops after a few program errors.
>Can one tell me why?

The reason is quite simple -- and it isn't an error of PBuild.exe!

PBuild is designed to process a "Project" text file, usually having an 
extension of ".XPJ" and a format very similar to Windows "*.INI" files.
PBuild can receive the filename of the project, as well as some other 
settings, in the form of runtime parameters.

It will read the project file, and find in it the name of the Compiler
program to be used (usually "XPP.exe"), the compiler flags to be used as
runtime parameters for the compiler, as well as some (redundant) settings
that can be set explicitly, like "DEBUG" or "GUI". It also gets similar
information about the Resource Compiler and Linker to be used, as well as
the runtime parameters for those programs.

In addition to those settings, PBuild gets "Targets" (or "Sub-Projects") 
and their corresponding "Source Files" and "Dependent Files" from the 
project file. It will then go its merry way, trying to process all the 
"Source" files through their "Dependencies" into the "Targets", by first 
calling the Resource Compiler for each ("*.ARC") Resource file, then 
calling the Compiler for each ("*.PRG") Program Source file, and then 
the Linker with all ("*.OBJ") Object, ("*.LIB") Library, and ("*.RES") 
Resource files for each ("*.EXE" or "*.DLL) Target -- as long as the
dependent or target file isn't newer than the source file. It will do 
this for all specified targets and all files of each target, until one 
of the three programs that it calls will return an ErrorLevel other (or 
greater) than Zero.

So, as soon as the Resource Compiler (ARC.exe), the Compiler (XPP.exe) or
the Linker (ALink.exe) returns with an "Error" code, PBuild will stop the 
processing of all further files -- which is what you don't like about it.

As XPP.exe will always return the number of errors it finds, even if you 
set the "/err:" or the "/s" compiler switches, PBuild will always stop 
after the first program with errors that XPP.exe reports.

What you actually want is a feature request for PBuild, which you should 
post to the WishList NewsGroup and/or email to Alaska. This feature 
request would be a new PBuild option -- to be implemented as a new setting 
and/or as a new runtime parameter -- that would make PBuild ignore the 
return value (or ErroLevels) of the Compiler -- as well as the Resource 
Compiler and Linker -- so that a complete Project file, with possibly 
multiple Targets, can be processed, even if there are (any) errors.

This would be a worthwhile feature to have, I think, but the absence of 
this feature isn't really an error of either PBuild or any of the other 
programs involved, by any stretch of the imagination!

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Hi Andreas:
good morning.
Many thanks.
Your explanation was very good.
I'll post my desire in the Wish List as you suggested and I hope people join 
to me.

Beling
Best regards

Andreas Gehrs-Pahl escreveu:
> Carlos,
> 
>> The PBuild stops after a few program errors.
>> Can one tell me why?
> 
> The reason is quite simple -- and it isn't an error of PBuild.exe!
> 
> PBuild is designed to process a "Project" text file, usually having an 
> extension of ".XPJ" and a format very similar to Windows "*.INI" files.
> PBuild can receive the filename of the project, as well as some other 
> settings, in the form of runtime parameters.
> 
> It will read the project file, and find in it the name of the Compiler
> program to be used (usually "XPP.exe"), the compiler flags to be used as
> runtime parameters for the compiler, as well as some (redundant) settings
> that can be set explicitly, like "DEBUG" or "GUI". It also gets similar
> information about the Resource Compiler and Linker to be used, as well as
> the runtime parameters for those programs.
> 
> In addition to those settings, PBuild gets "Targets" (or "Sub-Projects") 
> and their corresponding "Source Files" and "Dependent Files" from the 
> project file. It will then go its merry way, trying to process all the 
> "Source" files through their "Dependencies" into the "Targets", by first 
> calling the Resource Compiler for each ("*.ARC") Resource file, then 
> calling the Compiler for each ("*.PRG") Program Source file, and then 
> the Linker with all ("*.OBJ") Object, ("*.LIB") Library, and ("*.RES") 
> Resource files for each ("*.EXE" or "*.DLL) Target -- as long as the
> dependent or target file isn't newer than the source file. It will do 
> this for all specified targets and all files of each target, until one 
> of the three programs that it calls will return an ErrorLevel other (or 
> greater) than Zero.
> 
> So, as soon as the Resource Compiler (ARC.exe), the Compiler (XPP.exe) or
> the Linker (ALink.exe) returns with an "Error" code, PBuild will stop the 
> processing of all further files -- which is what you don't like about it.
> 
> As XPP.exe will always return the number of errors it finds, even if you 
> set the "/err:" or the "/s" compiler switches, PBuild will always stop 
> after the first program with errors that XPP.exe reports.
> 
> What you actually want is a feature request for PBuild, which you should 
> post to the WishList NewsGroup and/or email to Alaska. This feature 
> request would be a new PBuild option -- to be implemented as a new setting 
> and/or as a new runtime parameter -- that would make PBuild ignore the 
> return value (or ErroLevels) of the Compiler -- as well as the Resource 
> Compiler and Linker -- so that a complete Project file, with possibly 
> multiple Targets, can be processed, even if there are (any) errors.
> 
> This would be a worthwhile feature to have, I think, but the absence of 
> this feature isn't really an error of either PBuild or any of the other 
> programs involved, by any stretch of the imagination!
> 
> -- Andreas
> 
> ---                                                                      ---
>   Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>   415 Gute Street                     or: Andreas@DDPSoftware.com
>   Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
>   Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
> ---                                                                      ---