Author Topic: Are There Embedded Compiler Switches  (Read 4102 times)

Offline Workalot

  • Single posting newcomer
  • *
  • Posts: 2
Are There Embedded Compiler Switches
« on: January 15, 2013, 07:07:27 am »
Trying to get an Open Watcom 16-bit for DOS to go.

Have got to a point where Code::Blocks is being built (svn8784) with MinGW 4.7.1 once compilerXX .h/cpp and compilerXXgenerator .h/cpp were created and included and compilergcc.cpp modified accordingly.

And once the options_xx.xml file made sense, well indeed DOS .exes are being produced by the svn build. But there is an oddity in that some compiler switches are appearing in the command line and their origin is unknown.  It seems they are hard coded. Or perhaps a resource file may be involved.

Looking for some indicators.

Just so it is mentioned, found it useful to validate the options_xx.xml file at http://www.w3schools.com/xml/xml_validator.asp. An invalid xml is reported by Code::Blocks as a missing file rather than an invalid file.

Regards,

 

Offline Workalot

  • Single posting newcomer
  • *
  • Posts: 2
Re: Are There Embedded Compiler Switches
« Reply #1 on: January 17, 2013, 08:41:00 am »
To answer my own question - flag setting within the compilerxxgenerator.cpp is translating switches (well the Open Watcom one is doing this). This behaviour of course can be adjusted to suit.

But could I be allowed to make this observation...

1) Some toolset linkers call for comma separated object files (OW for one). Yet in sdk\compilercommandgenerator.cpp at line 449 the call to...

  macro.Replace(_T($link_objects"), tmpObject );

... is based on a tmpObject having space separated object files.

Would it be sensible to have it so that line 449 is executed only after a call to a function (sorry method) within the compiler specific .cpps which would adjust tmpObject?