Adding compilation / lex flags to a ninja running build

[Albert]

When building a project with make I can define a rule like:
    /usr/bin/flex.exe $(LEX_FLAGS) -ofile.cpp file.l
where LEX_FLAGS can be defined in the Makefile or outside the Makefile and can be altered by means of:
    make LEX_FLAGS=-d

I want to do the same with ninja, but I don't see a possibility to do it. I tried numerous possibilities but failed.

Any pointers?

Albert

[Charlie Dyson]

I agree it would be nice to pass a bit more data into ninja in this way. This will probably get shot down with the "you should do it in the generator" argument though! In this case, that might be the best way to go?

Another problem is that because ninja keeps track of the command used to build something, you may or may not want your changing custom flags to cause targets to be rebuilt.

For cases where I want to pass some extra information in *and it does not affect the output* (e.g. enabling distcc), I use environment variables with defaults. Not a very nice solution, but it means I can enable/disable running build jobs on other hosts without changing the commandline and thus rebuilding things unnecessarily.

[Albert]

Small clarification and addition to my original post and the remark from Charlie Dyson that the suggestion will be shot down with "you should do it in the generator" .

The problem is that in some cases (i.e. my use case) it is not possible / very highly undesirable to use the generator part as this would influence the complete build.

Use case (doygen):
- numerous lex (.l) files of which one has to be debugged by means of the afore mentioned -d flag.
The -d flag generates already quite a bit of output. In case we would use the -d flag in the generator state this would mean that all lex files would output a lot of output and the complete output would be far too big to handle properly.
When the -d flag is issued at "compile" time with a touch on the appropriate touch on the lex file, only this file is regenerated and the output is limited to the relevant part.
Further advantage in this case is the build speed (I think this is also one of the objectives of Ninja), regenerating 1 or many objects from the lex files (in case of doxygen 18 files).

A remark to the environment case.
- This is less convenient: one has to set a variable and not forget to unset it again as otherwise the next builds will use this as well. compared to the fact that it can be set on the build line directly.

For the time being I will examine the possibilities of the environment variable.

[Peter Collingbourne]

If this is just for debugging a single file, you can easily rebuild just that file with custom flags without help from the generator. Basically you run "ninja -t commands" to extract the compile command for that file, then append your custom flags and run the command. I use this trick all the time to rebuild individual files with custom flags for testing/debugging purposes, so much so that I wrapped it into a shell script that I've attached.

Peter

--
You received this message because you are subscribed to the Google Groups "ninja-build" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ninja-build+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-- 

Peter

[Albert]

Nice possibility as well, and definitely has some potential, but it has one drawback (in my case). After the flex has run the normal compiler and linker have to run.
So either I should, in that case:
-  run the 'flex replacement' followed by a 'normal' ninja run
or
-  I should incorporate the compilation and linking in the replacement script.

I think all a bit artificial for something in a build environment and in case of multiple files multiple runs (it can happen that I need / want to debug 2 files simultaneously)

Albert

Virus-free. www.avg.com