Jesus Calvino-Fraga wrote:
> Hi Borut,
> I borrowed the idea of a cfg file from a Borland C compiler. It
> seemed to work well for them for many years and several thousands of users.
Don't forget that Borland C was designed to run on a single user OS-es
(DOS and Windows), while sdcc is designed to run also on multi user
OS-es (unix, ...). Maybe a better idea would be to use an environment
variable instead of cfg file, but this method has weakness too and I'm
not convinced we really need it.
> The reason I added the cfg functionality is to work around the future
> deprecation of many keywords, such as 'bit', 'interrupt', etc. by
> defining replacement macros by adding lines like -Dbit==__bit.
I think that the Maarten proposition to "create a new header file with
macros for the old keywords defined in their new form" is much better
> By the way, I think that such deprecation will make sdcc even less
> compatible with other 8051 compilers and many textbooks that use
> Keil's 8051 compiler.
I'm not a 8051 and Keil expert but I think that sdcc is already not
compatible with Keil. Why we should delude ourselves and sdcc users
about that? Maybe Keil and other 8051 compilers should become ISO/IEC C
standard (and sdcc) compatible...
> Regarding the coding style: I changed the function so to match the
> rest of the file.
> At 03:50 AM 16/01/2010, Borut Razem wrote:
>> I saw that you added the ReadcfgFile() function to SDCCmain.c, which
>> reads the command line options from the sdcc.cfg file if it exists in
>> the current directory or in the sdcc binariy directory.
>> I have big concerns abut this functionality:
>> * it is very easy to forget that you created the cfg file after a
>> month or later, specially if he put it into sdcc binary directory.
>> Then the user will wonder why sdcc is not working as expected and
>> he will report bugs, which will be very difficult to solve: if the
>> user forgot abut cfg files, how the sdcc developer - bug fixer -
>> can know about them? And what if different users are using the
>> same machine (for example multi user unix) and someone created the
>> cfg file and didn't tell to others?
>> * the cfg file is taken from the current directory, not from the
>> directory where source file resides: you can run the sdcc from any
>> directory and compile the files in any other directory, so this
>> creates a big mess: the compiler results will depend on directory
>> from where the compiler is executed!
>> * if the compile process uses makefiles or other build environments,
>> it is usually supposed that they take the full control on command
>> line options, so we have a confusing situation again
>> I think you can achieve the similar functionality by using scripts,
>> batch files or makefiles, so I propose to revert the changes.
>> I also noticed that you don't follow the SDCC coding style at
>> * tabs instead spaces
>> * incorrect indentation
>> * inconsistent using of spaces around operators
>> * non consistent function name
>> * ...
>> Please pay attention on the coding style in the future commits.