Wondering if any of you could help me with a very basic question.
I’m having a bit of trouble trying to build external source code into my application. I’ve specified -inc in my Project Wizard “wmnew script additional settings”, and when I compile, it manages to find the first file I try to include, but when that file tries to include another file in the same directory, it can’t find it. What am I doing wrong? How can I set up global include paths for the entire build?
Sorry if this seems like a very elementary question. I can’t find anything in any of the manuals that I have (maybe I don’t have all of them?), and searching the forums gives me massive amounts of results, but nothing relevant.
Also I’ve noticed the Tools Manual is mentioned a lot on this forum, but nobody mentions where I can find it. The website search comes up with nothing.
The tools manual is in OpenAT/IDE/IDE//doc/TM_Tools_Manual_for_Open_AT.pdf
Are you trying to include a files that doesn’t have the .h extension? The documentation seems to imply that it only copies the .h files to ./{compiler}/out/.
Anyway, the solution I think you’re looking for is to use the -noppinc parameter when calling wmnew instead of using -inc.
No they’re .h extension. The -noppinc option works - thanks! We’re actually trying to get C++ / STL working, though I’m beginning to wonder whether it’s a good idea. I’ve got C++ to work, but I can’t get STL to compile - even the
new
operator isn’t linked in, so I’m not sure I’ve got all the libraries linking properly. Maybe it’s not such a good idea, but we were hoping to just port some software over, so it would be less work than rewriting it in C.
the Open AT IDE (before M2MStudio) has a couple of puzzling “features”. Among others, it preprocesses your header files and puts all resulting header files in a single directory. Worse thing is, this preprocessor does nothing on user application code, so it basically is an extremely slow file copy! As a result, if you specify file paths within your #include directives, you’re screwed. For some reason, it also hates the angles brackets in #include< >, so you should change them into quotes #include " ". It tries to build dependencies automatically, but fails in complex case (i.e. when there are several files and/or dependencies between them! ), so you’d spend ridiculous amounts of time debugging the system, based on scripts-that-generate-makefiles-depending-on-a-dozen-of-submakefiles-to-finally-generate-a-script-that-only-works-on-a-single-deprecated-version-of-cygwin. Of course, in addition to usually fail at one point or another, this contraption takes amazingly long to do so. I must have forgotten many other quirks of the system, but the final result is that I’m, as many other people, unable to use it for anything non-trivial. Plus, given that Wavecom is releasing a new IDE remade from scratch, you shouldn’t expect a fix for the old one.
If you want to do something more complex than changing a couple of lines in a Wavecom-provided sample, you cannot rely on the provided build system; search this forum for “minimalist makefiles” and start from there.
), so you’d spend ridiculous amounts of time debugging the system, based on scripts-that-generate-makefiles-depending-on-a-dozen-of-submakefiles-to-finally-generate-a-script-that-only-works-on-a-single-deprecated-version-of-cygwin. Of course, in addition to usually fail at one point or another, this contraption takes amazingly long to do so. I must have forgotten many other quirks of the system, but the final result is that I’m, as many other people, unable to use it for anything non-trivial. Plus, given that Wavecom is releasing a new IDE remade from scratch, you shouldn’t expect a fix for the old one.