I finally have a comfortable-enough workflow for writing my flex programs, and I'll work bison into it soon (I dabbled with it before but I restarted my project entirely).
flex yy.l; flex flip.l will generate a lex.yy.c and lex.flip.ccorrectly, since I use the prefix option. But I am curious why flex yy.l flip.l or flex *.l does not.
gcc lex* seems to work perfectly fine when all .c files are correctly generated, as by the first command, but trying the same shortcut with flex produces a single lex.yy.c file, which seemed valid up until the unprocessed flip.l file pasted on the end, preventing gcc compilation.
Is this just flex telling me my workflow is dumb and I should use more start conditions in a big file? I'd prefer not to, at least until I have a more complete program to tweak for speed.
My workflow is:
fg 1; fg 2; fg 3; fg 4; flex a.l; flex flip.l; flex rot.l; gcc -g lex*; ./a.out < in
With nano editors as jobs 1, 2, 3, 4 to fg out of the background.
I'm lexing the file in this order: flip, rot, a, rot, flip. And it works, and I can even use preprocessor definitions gcc -DALONE to correctly compile my .c files alone, for testing.
I think what flex is telling you, if anything, is to learn how to use make rather than trying to put together massive build commands.
It's true that flex will only process one file per invocation. On the other hand, both gcc and clang are simply drivers which invoke the actual compiler(s) and linker(s) so that you don't have to write more complicated build recipes. You could easily write a little driver program which invoked flex multiple times, once per argument, but it would be even simpler to use make, with the additional advantage that flex would only be invoked as necessary.
In fact, most large C projects do not use gcc's ability to compile multiple files in a single invocation. Instead, they let make figure out which object files need to be rebuilt (because the corresponding source file changed), thereby considerably speeding up the debug/edit/build cycle.