I am trying to run codeql on Chromium among a few other open-source software, and I was wondering if it is possible to compile a single file from the full source code, because my machine takes a long time to compile such huge codebases.
For example, is it possible to compile the media/filters/ffmpeg_video_decoder.cc file only?
Compiling is not the issue. If you only compile one source file, it will be missing several functions that would be added to the final binary in the linker phase.
https://en.wikipedia.org/wiki/Linker_(computing)
Only compiling one file will (most probably) not make a working binary, as you need a main function along with all the other code.
From a quick CTRL-F through the source code, a main function, which is critical for the program to run, is absent from the file you mentioned, so you definitely won't be able to make a working executable.
If you're making a .lib (library) file, it might work, although you're almost certainly going to run into undefined references, as the code is broken apart among many files.
Related
Let say we have a large code base and we are doing development in C++. Do we have to recompile everytime in order to test the code?
If yes then it is going to take ages to do development.
What's the solution to this problem?
Yes, you'll definitely need to compile C++ code if you want to test it. C++ code can't be executed without being compiled.
However, if you organize your project smartly, compilation could take only a few seconds, or maybe up to a minute, even if there are thousand (or even more) of files.
By default, your build system will run an incremental build, except if you explicitly request a "rebuild" or did a "clean" previously. It will then invoke the compiler/linker accordingly and make sure it compiles/links only what needs to be (if a cpp file did not change, no need to compile it, this is all based on file timestamps, if the "object" file (generated) is older than the cpp file (source), the build system knows it's up-to-date and won't generate it again. If you use Visual Studio and/or CMake or whatever IDE, build system, they all support that!
Additionally, you can follow some guidelines to make this even faster:
Firstly, organize your project in modules (libraries), ideally with dynamic link. Then when a file from a library is changed, only this library needs to be compiled (other libraries or programs using the modified library won't have to be compiled again).
When you'll modify only an implementation file (cpp file), only this file + link of the module using it will be needed.
When you'll modify an header file (h file), all cpp files including it will need to be recompiled, so you must be careful to optimize your includes. Prefer forward declaration (see why here)to includes whenever it's possible (else, your header becomes a dependency of all cpp files using the other header file including yours...as a cascade, modifying this header file will end up requiring compilation of tones of cpp files). Don't include files you don't need (because it will fire a new useless build when the header file changes). Possibly use precompiled headers to speedup compilation.
Note: As commented, there are apparently some tools that can interpret C++ without compiling it...but that's not what C++ was designed for at the first time. And I doubt they will be fast as compiled code at runtime....so you'll probably save 20sec of incremental build time and then loose minutes at runtime....
I've taken the "edge" sample file and moved the appropriate source files into the directory, changing #include(s) where needed to account for the directory structure and not being setup with the library and all that. The goal being to make a more portable batch of code to try some things out. I was wondering, given the list of linker errors (lots of undefined this and that.) Would it A, be possible to take the source and include it all in a way that I won't need linking? And if so B, what would be the suggested route to find which source files have the right code to counter all the undefined stuff I get while linking?
I understand this is a general question, but it requires a general answer and I haven't seen anyone answer this here or anywhere else. I would think it's entirely possible though, OpenCV is BSD and all the source to compile it into the library is available, so I would imagine you could skip the linking to an external library step if you had the source for the library in your project code. Thanks a million to whoever can help me out or lead me into the right direction, it's much appreciated.
If your project requires fully open source code, you can do what you want. Of course, to isolate what you need from OpenCV will be a demanding task. To do that, you need to manually locate the files including the missing objects. In MS explorer you search using "inside the file" query, in linux console you can use "find | grep" combo command.
I sometimes move source files(opencv/modules/*/src) locally in my projects to customize some functions. I also keep the linked libraries which compiler puts second in priority and they become inactive but they still exists in their original form occupying some negligible useless MBs.
I have a c++ project with many files. When I build the project making even small changes to the code, It recompiles a large no of files. This is increasing the compile time of the project. So I need suggestion about the ways I can improve the structure of the project or any other optimisations possible which will help in reducing the compile time of the project.
Also there are a couple of files which are getting recompiled even when I make no changes to the project. Somehow make doesn't detect that those files need not be recompiled or may be I am missing something.
I am using Codelite on linux(Ubuntu) for my project. The language is C++.
The link provided above will give you a detailed explanation. Just to put it in a lighter way I am adding a few more things.
If you change something in a CPP file only that file will get recompiled. If it is a header file then it will be a different story. If you have a header file included across multiple modules and when you make changes to that header file, all the associated CPP files will get compiled and again that is the way it should be. So you need to be careful while writing the code if you really care about this aspect. At a later stage it will be difficult to manage such things.
Regarding the compilation of some files even if you don't change anything may happen when
1] we tell the compiler to do so.
2] some CPP or header files are generated or modified automatically while run your build
3] there is a change in file time stamp
4] there is a change in folder name/structure
Last but not least, also try changing the code lite build target.
These are the possibilities I know. There will be more [definitely :)]...
Recently I discovered a problem on the midas and I fixed it, the problem now is that I want to use MidasLib not the midas.dll and with the source code I'm only able to build the DLL.
The source is C++ and I have very few knowledge with it. I know the MidasLib.pas uses internally midas.obj, so I need to create it to statically link the midas to my application. How to do it on C++ Builder? (XE)
When you compile C++ code, the compiler creates an .OBJ file for each .CPP/.C file you have and saves them somewhere on your computer. What happens in most cases is that one would run a linker on all of those .OBJ files to join them into a single EXE or DLL, but in your case you don't need those results. Your C++ Builder is, like most programming IDEs, automatically doing both the compilation and linking.
If you just want the .OBJ, you need to find where in your project folder C++ Builder is placing its .OBJ files (called its "intermediate output", typically, as it is the intermediate step between compilation and linking). So you must have a source file called midas.cpp or midas.c that produces a corresponding output file called midas.obj.
I'm wondering if it's possible to combine multiple DLL's into 1. I'm currently working on a C++ project that is dependent on many dynamic link libraries,so would it be possible to combine them into 1 DLL file, and if so, how would I do that?
I do have the source code for these DLLs, yes.
Just combine all the source files from all the DLL projects into a single DLL project?
And if you have multiple *.def files (one for each project) then combine them into a single *.def file.
Realistically, no. In theory, if you wanted to badly enough you could do something like disassembling all of them, then re-assembling all the separate files into object files, then re-linking those object files into one big DLL. Getting this to actually work would usually be non-trivial though -- there are likely to be things like conflicting symbol names that would require considerable work to get around.
A rather cleaner possibility would be to package all the DLLs into a zip file (or whatever you prefer) and have a small program to unzip them to a temporary directory, run the main program, and then erase the DLLs from that directory. This has a few problems of its own though (e.g., leaving copies of the files if the machine crashes/loses power/whatever during a run).
Edit: Since you have the source code, using it to build all the code into a single DLL is much more reasonable. For the most part, it's just a matter of adding all the source files to a single project that creates one DLL as its output. You may (easily) run into some symbol conflicts. Given access to the source code, the obvious way to deal with this would be by putting things into namespaces.
Its certainly not infeasible. The Dll format contains all the information you need to merge the code and data from multiple dlls into one, and rebase the resulting code.
this is not a standard feature of any toolchain I can think of though.