Folder Setup - Path With '-' character

Parser?

The compiler parser is the little guy who understands the C or C++ source code.

This is a question about how the IDE (not the compiler) supports a path that contains a space.

Do avoid to use a path with spaces.

This is a common problem with almost all command-line tools - or at least with the tools who creates the command-lines, without specifying quotation marks around the path, or embedding break characters before problematic characters.

But no: This has nothing to do with the compiler parser. And it isn't the '-' that is the problem, but the spaces.

If you think about it - it is totally impossible for a command line tool to know if a space on the command line represents the separation between two options, or if it is part of a command.

The Win32 command-line do cheat a bit. If you run a built-in command that can only take a single file name (for example CD) then it assumes that a space in the middle is part of the file name. M$ thought this was clever, but it can in some situations be dangerous. Tools should not perform arbitrary guesses.

Sorry about parse mistake.

You're sure. The problem is about Uvision parse (that read command line) routine.

But on Uvision on 8.12 C51 distribution runs perfectly with the same folder framework. I believe that problem is on MDK ARM Uvision release (3.20).

Regards

I've open one C51 project.
(uV3 3.6)

Let's observe how String Control is mounted.

LARGE OPTIMIZE (9,SPEED) BROWSE ORDER INCDIR(..\A - Source) DEBUG OBJECTEXTEND CODE LISTINCLUDE SYMBOLS TABS (2)

:)

So...the INCDIR (PATH) ...options has spaces and '-' char... no problem....

You still haven't realized how a command line works.

Your first example (that gave an error) will split into the following (by windows itself):

1: -c
2: --device
3: DARMP
4: -g
5: -O0
6: --apcs=interwork
7: -I..\A
8: -
9: Source
10: -I
11: C:\Keil MDK 3.20\ARM\INC\Philips
12: -o
13: *.o
14: --omf_browse
15: *.crf
16: --depend
17: *.d

And as you can see, your path "..\A - Source" gets splitted into three parameters. Not by the Keil compiler, but the Windows. The same thing would happen if the command line was processed on a Unix system.

Your second example - after you have added quotation marks - gets expanded into:

1: -c
2: --device
3: DARMP
4: -g
5: -O0
6: --apcs=interwork
7: -ID:\Firmware\APIDM01\B - Releases\V1\A - Source
8: -I
9: C:\Keil MDK 3.20\ARM\INC\Philips
10: -o
11: *.o
12: --omf_browse
13: *.crf
14: --depend
15: *.d

And in this case, the compiler will get the include path as a single parameter.

Then you make a new post, where you compare with the C51 environment. But we never get to know if the data is sent to the compiler on a command line, or by the use of a file. C51 is old, and a lot of Windows-based IDE made use of parameter files to get around the short command line supported by MS-DOS and early versions of Windows.

However, note that the path is bracketed:

INCDIR(..\A - Source)

In this case, the compiler can use this bracketing to handle a path with spaces.

So, once more: Your problem is with spaces, not with the '-' character. And as soon as you make sure that any path containing spaces are put within quotation marks, the operating system - not the compiler - will stop splitting the path into multiple parameters.

Just a footnote, since you are not so comfortable with command lines.

Quote a lot of programs have a special meaning for a command line parameter that consists of a single dash.

It normally means that the program should read from stdin or should write to stdout.

That is probably the reason why you get the strange error message. When processing a file, the compiler can specify a file name and line number. That isn't so easy when it is requested to read from stdin.