I'm Flexing a file with the
%option nounput
Option and using the command line
flex --nounput
And flex version 2.5.35.
However, the cpp output still contains the line
#define unput(c) yyunput( c, (yytext_ptr) )
And this causes compilation problems with g++ since unput is not used.
Is there some way to fix this problem in a "clean" way? The two dirty ways are obvious:
Use unput in some useless way.
Remove the line automatically from the generated cpp file using some script.
(I tried to flag this question as "problem no longer reproducible" but the flag timed-out/aged away. I'm answering it so that it does not remain an open unanswered question.)
As mentioned by #akond:
I don't experience this problem. The version I am using is the same (flex 2.5.35). %option nounput does the trick for me.
I also tried this on version 2.5.4 and can confirm there is no issue. The option --nounput is no longer recognised or documented; however, the %option nounput remains in the manual.
The cpp output still does contain the line #define unput(c) yyunput( c, yytext_ptr ) but this does not seem to generate any g++ errors for me. Are you using -pedantic-errors or some other similar option perhaps?
Good program but badly out of date documentation.
I found that version 2.6.4 accepts the nounput option and does the right thing.
Related
Not sure what forum is best for this.
I created a (default) C++-11 tool project in Xcode 8.0 and referenced Eigen/Core using Eigen 3.2.10. I got 47 warnings before writing any code, all related to Doxygen comments, e.g.,
Empty paragraph passed to '\sa' command (in Comments.h, line 52)
Is there a fix for this?
Thanks.
Answered:
Turns out there is a global flag for documentation warnings that can be turned off.
When I type 'f' in a C source file, my emacs with semantic installed and working
will show 25 completion matches, for functions like fclose, fread, and so on (only stdio.h
included)... but not fopen! Why?
Plus, same problem with opendir and readdir, with sys/types.h and dirent.h included.
P.S. semantic has all my sympathy, as upon my personal reading glibc header files showed
as a horrible mess of #ifnded and alikes.
'fopen' is turning up fine for me. Are you by any chance working on OS X? I remember that there were some preprocessor macros there which confused Semantic. Otherwise, your best chance for help is posting to the CEDET-devel mailing list, stating the CEDET version you're using and posting the exact definition of the 'fopen' function which apparently cannot be parsed.
I am attempting to use clock_gettime( CLOCK_MONOTONIC, ts ). I have included time.h, and linked to librt (I think). I still get the error that CLOCK_MONOTONIC is undefined. (EDIT: error text added)
Symbol 'CLOCK_MONOTONIC' could not be resolved ... Semantic Error
c++ in eclipse. In myrojname->properties->C/C++ Build->GCC C++ Linker->libraries I added "rt". The resulting command line includes -lrt.
I tried a much simpler scratch program and compiled from the command line with g++ -o mytest mytest.cpp -lrt and it works great.
So, what am I missing?
I think that's actually an error message coming out of the CDT static analyser, not something from the compiler itself.
And I think it's complaining about the code itself rather than something missing from the linkage objects, so whether you link with rt or not is not relevant (for this particular issue anyway).
You should go into the C++ settings, specifically the include paths, and ensure that all needed directories are listed there.
I'm writing some MATLAB code, and I want to use some optimized C routines. I have the C source code, and it works just fine. I've created a MEX file and am capable of compiling it provided that it is in the same folder as the optimized C routines. However, I want to be able to distribute this code to others on various platforms. Since MEX files are binaries, each individual must (likely) recompile on their own machines. That is fine, but I want to make the process as painless as possible.
Currently, if all of the files are in the same directory, then calling something like
mex mexfile.c other1.o other2.o other3.o
from that directory works just fine as you would expect. For organizational purposes, however, I'd like for the C code to be in its own (sub)directory, say code. Unfortunately, if I structure things like this, the mex command errors out (the errors differ based on the different things that I've tried). I've tried things like
mex mexfile.c code/other1.o code/other2.o code/other3.o
and the -Ipathname and -Lfolder options on the mex command, but these haven't worked for me. I would think that there has to be a simple way to do what I'm wanting to do, but I just can't find the appropriate documentation or figure it out myself. Any help would be appreciated.
[OP's solution converted to answer below]
In the setup given above, using the following command works as desired for me:
mex -Icode mexfile.c code/other1.o code/other2.o code/other3.o
I stumbled across this solution while regenerating error messages.
I'm guessing that this is just the appropriate syntax for the -Ipathname option to the mex command, but I can't find documentation to support this conclusion. If anyone else can provide a link to actual documentation, that would certainly be better than a potential solution that just happened to work for me.
I use something along the lines of
emlc -I './somedir/' -o sourcefilemex -T mex sourcefile
By changing the -T argument you can generate mex code or embeddable C. That's handy.
I usually have an environment setting for MAKE_MODE (Windows XP, using GNU make, both under Cygwin and native)
set MAKE_MODE=UNIX
I now found differences between my build server (which has no MAKE_MODE defined) and a local build. This may be something completely different, but it got me wondering what other values I could specify for MAKE_MODE.
I think I know that MAKE_MODE=UNIX is suppose to tell GNU make to use /bin/sh - if it finds it - , but I quickly checked the GNU make manual and couldn't find a description. A google search only told me what I already know, but doesn't give a valid alternative.
Is the only alternative to not define the variable? Does it have influence at all when using CMD.exe and a native version of GNU make?
EDIT: So far I have found references for the values 'unix', 'win32', 'null' and undefined, but no explanations, and no specifications. But a look at the source code for GNU make 3.82 shows not a single occurrence of the string "MAKE_MODE", so GNUmake itself apparently doesn't change its behavior when this environment variable is set or not.
EDIT2: I checked the source code for GNU make for MinGW, and again found nothing. Maybe it's CygWin specific?
EDIT3: I found a reference that it might be property of an old version of GNU make, so I checked version 3.75. No luck, the string MAKE_MODE does not appear in the source code at all. The next step really must be the Cygwin version of GNU make. I know from 10 years ago that the Cygwin port in those days was not integrated in the regular source tree.
I found an ancient mailing list entry on the Cygwin site, explaining the basic operational effect of MAKE_MODE. This definitely indicates that the variable has to do with the Cygwin implementation of GNU make.
I'll dig around in the source code, and add to this answer when I find more details.
UPDATE: In a more recent post by maintainer Christopher Faylor I found the following update for GNU make version 3.81:
Note that the --win32 command line option and "MAKE_MODE" environment
variable are no longer supported in Cygwin's make. If you need to use a
Makefile which contains MS-DOS path names, then please use a MinGW
version of make.
I've not really found the values allowed for MAKE_MODE, but it's not any more necessary or supported in most recent versions of GNU make for Cygwin, and it was used for supporting DOS filenames in Cygwin's make.
And if you really want to know the set of allowed values, look in the source for Cygwin's make version before 3.81-1. I guess the only useful value was unix, all others will have meant the same.
Case closed? There's still not many views here...