My C++ project includes a Bison parser. What is the scons function to call for building from ".l" and ".y" files (or alike)? By build I only mean compiling the grammar into source code.
I assume that building from lex/yacc files are natively supported, but I'm curious as to what would one need to do if one has to also build some files with an 'uncommon' compiler, say a DSL compiler for that specific project.
If you want to "teach" SCons how to process a new filetype, all you basically have to do is copying the command-line. Then you put this command into a so-called Builder, which will execute the required action at runtime and will care about the dependencies for you.
For a more detailed description of solutions to this problem, which actually depend on what exactly you want to accomplish, please have a look at our ToolsForFools guide.
Related
First, i know that make is used for building the code. But which code?
But what does it mean by building a code, and after executing the make command, what is presented to the user?
Second, how is it different from make build_for_e2e?
What Wikipedia tells about make
Make is a build automation tool that automatically builds executable programs and libraries from source code
Compilation process becomes big and complex in big projects, where numbers of files need to be compiled, with flags and libraries. Where it will become hard for people to compile it one by one. So these types of tools were introduced, there are more similar tools available for same use like cmake, gradle, maven. e2e's Build is also a form of build process, with different form of specifications.
For C people mostly use make. It is helpful for porting software packages in different systems.
How make is used:
As said make is a tool, which will be available in our system, we can execute it by giving command make in the directory which needs to be compiled. Then make looks for Makefile, which is provided in the package directory and it contains information about compilation of the project. Then make as per info gathered from Makefile, it compiles the package.
You can also create Makefile for your project, so that it can be also supported and compiled with make. Simple tutorial for it can be found here. For big projects you can use gnu autotools contains autoconf and automake which will help you to create your all files required by make automatically. You can find tutorial regarding it here and here . These contains some basic information, you can find some advance tutorial regarding autotools, use google for more information on it.
I want the compiler to run preprocessing, generate all the .i files like it normally does if I just use the "generate preprocessed file" option, and then run an external tool, wait for it to complete, and then go on with the compilation of those .i files (which by now can be modified of course).
If that is not possible, is there a way to run an external tool on every file that is being compiled before preprocessing and compilation? (Would probably be a hell to debug in environment like that, but still).
If there is no option like that, could this even be done at all? I mean, does the compiler even use those .i files, or are they just output for the user somehow?
Basically, is there any way to automatically tamper with the source before it is compiled, but without modifying the actual files?
Just for refs: I am trying to think of a smart way to obfuscate all the strings with minimum modification of the source.
Yes, you'd simply update your build system to have a preprocess step, obfuscate step, then compile-to-obj step. By default, most build systems merely merge all those to one step (and skip the obfuscate step). Should be no big deal with any "real" build system like Scons, waf, or even Make.
If you're using Visual Studio, then it is a bit more work. Microsoft wants you to write your build operations in MSBuild, and that's quite a bit of work, IMHO. It's not easy because MSVS is principally an IDE for iterative development, and NOT intended to be a build tool. It's not, and will never be, a build tool (even though it happens to do "build things", but only standard and very simple "build things"). But, you can still use the IDE with a different build tool. For example, we use Scons for our build, and it generates MSVS *.sln and *.vcproj files, and those files merely build with Scons (but all the files are edited in the MSVS IDE).
The simple answer: Your question is very simply a build-operations problem. It should be very straight-forward with any non-"toy" build system.
The distcc (distributed build tool) effectively preprocesses all files locally, then sends the *.i to remote compilers (that do not even need headers installed), and then ships back the *.obj. So, what you're talking about is pretty straight-forward.
Let x.cpp be your file you want to preprocess.
Set the compiler option to generate preprocessed output for x.cpp, let it be x.i.
Add the x.i to the project and set the "custom build tool" in the properties. Set the "output files" to x.preprocessed.cpp.
Add x.preprocessed.cpp to the project.
See msdn for details.
You should be able to perform a "Pre-Build Event" and plug in any external tools there. In VS200x it's under Configuration Properties -> Build Events -> Pre-Build Events.
Just use a decent build system. SCons, waf, or something else if you won't like those two.
You could use a make file to generate the .i files first, run your processing on them, then compile them.
What is a makefile and how do I use it?
A make file describes the compilation process. It describes which flags, compiler tools, linkers, etc. to use with which source code files and objects
More info
http://www.sis.pitt.edu/~mbsclass/tutorial/advanced/makefile/
The main purpose of a Makefile is to store every you need to build your project in one place. It contains the instructions for compiling your code, linking your compiled code, packaging the executables, extracting third party tools, and many other useful things. Pretty much any command you entire at the command line can be used in a makefile.
The advantage to using a makefile, when done correctly at least, is that anyone can easily build your entire project. It's as easy as typing make
An example of a Makefile for a windows project http://www.opussoftware.com/tutorial/TutMakefile.htm
I have a pre-processor that I'd like to run on my .cpp/.h files before compiling them. I created a Custom Build Rule and applied it to my project. This successfully runs the pre-processor, but it does not actually compile the files afterwards. So what I'd like to do is run my custom rule first and then run the C/C++ Compiler Tool as default.
I could do this with a pre-build step, but then I'd have to force processing of all source files in the project, when I really just want to process the source files that have changed.
Any help is appreciated!
With advanced builds you are generally better off using an external makefile. You can add this in to MS2008 as a custom tool.
See: Good techniques to use Makefiles in VisualStudio?
If you do not want to use external scripts, you may be able to get what you want by having two projects within your solution with the same files in them. You make one project a dependency of the other. In the dependent project use your custom build rule, in the top project do the real compile/build. Caveat emptor - I've not tried this.
Let us know how you get on.
I am developping a DSL with its own graphical editor. Such files have a .own extension. I also have a small tool that compiles .own files into .h files.
X.own --> X.h and X/*.h
I have written a simple .rules file to launch the generation.
My problem is the following :
Most of my source files include X.h, but a change in X.own does not mean the generated X.h (or any other generated file) will be different. This is dealt with by the generator through the use of temporary files and file comparison. But Visual Studio does not seem to know how to deal with all this. If i set the "output file(s)" property to the right file(s), it always assumes they will be changed. If i don't, it generates its build process assuming they won't be !
How can i make things right ?
1) Launch custom build tool
2) Compute build process based on dependencies
Don't use the custom build tool options but instead set it up as a pre-build event for the solution (this can take a general command line, just like the custom build tool). This way MSVS will not examine the generated files. As long as they are #included or listed in the solution explorer they should be compiled fine as the generation of the .h files will happen before any other compilation.
I find the custom build tool is not so useful as the pre- and post- build events in general, because of the way it expects files to be generated or modified. You might find this tool useful for other things in the future (e.g. to compress the .exe after build, to generate other dependencies correctly, to ensure files are in place etc...)
There is a nice diagram showing where to find these options in the solution properties here
jheriko's answer is interesting, because it provides a way to launch custom tool, then generate build dependencies. But it's not very usable, because you then lose all possibilities to use "custom build tools" toolkit, in which you can
choose to always compile files with some precise extension
manually skip custom build for a particular file in a particular project configuration (and visualize this decision)
There is no way (or at least i have found none) to "have it all". The only way i have found is to have the custom build tool return a non-zero number when files have been updated, with a message to the user explaining that it is not an error and inviting him to launch build again. The next time, custom build tool is launched again (not optimal, but the tool i use is pretty fast) but modifies no new file, and build process goes on, using valid dependencies.
Note : the approach described above does not work with Incredibuild, which seems to ignore project build order.