PBWin Compiler can't locate the .inc folder when run from a command line

[Ray Crumrine]

file compiles fine when run from the ide. I created a 2 line batch file to be sure I wasn't doing something wrong. Page 15 of the docs says the /I parameter is supposed to specify the path. The same folder is set in the PBEdit gui.

set var1="e:\program files (x86)\pbwin10\winapi"
set var2="e:\network_enable\test.BAS"
pbwin.exe /I %var1% %var2%

I can tell it is reading the source file because it always errors out on line 29. The fist INCLUDE file listed. tried using a : and = sign to separate the /I but neither one made any difference.

[Stuart McLachlan]

Try with no space after /I ( are you sure that is a capital eye and not a lower case ell? )

You also need quotes around the include path since there are spaces in it.

[Ray Crumrine]

Tried I,i L,l. When the batch file runs there are quotes around both strings. I saw some old posts about a similar issue but didn't see any resolution. I thought maybe it wasn't using PBWin.exe when run from the editor but when I renamed PBWin.exe there was no compilation.

[Stuart McLachlan]

Works for me

[Dave Biggs]

You can put the /I at the beginning of var1 too (again no space!)..

[Ray Crumrine]

I discovered several gotchas about using / running the PBWin compiler from a command window from this exercise. None of them mentioned in the manual.

[Stuart McLachlan]

I discovered several gotchas about using / running the PBWin compiler from a command window from this exercise. None of them mentioned in the manual.

Please tell us what they are.

[Ray Crumrine]

Glad to. 1. As both you and Dave Biggs noted, a space [nor anything else] is allowed after the /I and before the path-to the WinApi folder. That is Ok as long as you enclose the path in quotes but that isn't required either. If your path was I:\blah-blah\WinApi I suppose the quotes would be required then.

2. Related, but applies. PBForms insists on putting a line into your source #RESOURCE "YourFileName.pbr" and does not include the path. If compiled in the IDE it is accepted but if you try to compile it from a command line it won't compile, and you have to look closely at the error message.

3. If you compile from the IDE, the resulting exe file is placed in the same folder as your source file but if you compile from a command window the .exe "lands" in whatever folder you ran the compile command from.

All this was exacerbated because I was trying out a new editor and had to fabricate strings to put into the editors config in order to be able to directly compile from within that editor.

[Stuart McLachlan]

Glad to. 1. As both you and Dave Biggs noted, a space [nor anything else] is allowed after the /I and before the path-to the WinApi folder. That is Ok as long as you enclose the path in quotes but that isn't required either. If your path was I:\blah-blah\WinApi I suppose the quotes would be required then.

I presume you mean "not" allowed.
Help clearly shows the command line switches without a space. It also states that LFNs should be quoted.
Both are expected behaviour with a Windows CLI regardless of what application is being invoked.

2. Related, but applies. PBForms insists on putting a line into your source #RESOURCE "YourFileName.pbr" and does not include the path. If compiled in the IDE it is accepted but if you try to compile it from a command line it won't compile, and you have to look closely at the error message.

That's because it puts the .pbr file in the same folder as the primary .bas file under te assumption that you will be compiling from that folder (as PBEdit does)
Again expected behaviour

3. If you compile from the IDE, the resulting exe file is placed in the same folder as your source file but if you compile from a command window the .exe "lands" in whatever folder you ran the compile command from.
The IDE sets the current directory to the location of te primary .bas file. The compiler creating the .exe in the current directory is the only practical way to do it. It's standard Windows behaviour with any application run from a directory.
Again expected behaviour.

All this was exacerbated because I was trying out a new editor and had to fabricate strings to put into the editors config in order to be able to directly compile from within that editor.

It's not surprising that theses "gotchas" are not mentioned in the manual. None of them are related specifically to PowerBASIC. They just reflect a limited understanding of the concept of "current directory" and the effect of spaces in a CLI in Windows.

Unless you grasp that, you are likely to have major problems using SHELL or ShellExecute in a PB application.

[Ray Crumrine]

It also states that LFNs should be quoted.

I knew that. I was referring to a path without spaces. I tested with "/IE:\WinAPI" [no space] and it took it fine.

The IDE sets the current directory

I was aware of that also. But when running from the command line it gets burdensome if you have long paths [with spaces].

[Michael Mattias]

Why the heck can't' you specifiy some option on the command line meaning, "Use the include paths defined in the compiler's INI file" eg " /I INIFILE" or something like that?

Might that not be useful? (I don't use command line compilation so I am not sure). If so I will send in a New Feature Suggestion.

MCM

[Ray Crumrine]

Why the heck can't' you specifiy some option on the command line meaning, "Use the include paths defined in the compiler's INI file" eg " /I INIFILE" or something like that?

Good suggestion. I was forced to a command line because I was trying out a new editor and had to come up with an appropriate command line in order to be able to Click-and-compile. I figured out three simple work arounds to the LFN and long paths stickyness.
1. Copy the entire WinApi folder [not the files] to the root of the hard drive.
2. I created a folder and specified it as "Initial directory" in my editor config. That way every .exe I compile will be placed there.
3. Last [but not least] edit the source generated by PBForms and add the complete path to the .pbr file

problems solved!

*edited* digging into the help file I found that PBWin does include a similar command line switch /C. It would have to be edited for every compile though because the last item in the file is the name of your source file.

[Michael Mattias]

I found that PBWin does include a similar command line switch /C.

While this DOES get rid of issues resulting from embedded spaces and other command-line typing issues, that is NOT the same as "use the compiler's (standard IDE) include path settings. Sure, you "could" use it, changing only the name of the source file if you are going to use your "standard compile options.

I will send in the NFS today.

MCM