Code snippet paths in GCC - gcc

Background: Keil C51 on a PC, currently moving to GCC (CrossPack-AVR) on an iMac.
Since I write firmware for micro's I have a lot of 'driver' source files etc. that I need to include with my programs, e.g. a LCD driver, i.e. reusing code. These code snippets (.c and .h files) live sub folders in a /snippets/ folder, i.e. /snippets/lcd/. My /snippets/ used to be in a folder that also had a /projects/ folder for, well, projects or applications. I had considered putting them in a library but I use various architectures so it would not always work.
The Question: How can one set that up in GCC without having to specify absolute paths to the snippets in, for example, the various #include paths etc. so that the source file, of the included snippet, gets re-compiled along with the project that uses/includes it? Thus, if I improve on a snippet, it benefits all projects that is compiled/re-compiled subsequently?
I looked around on google but must be using the wrong search term.
Thanks!

I think make files will do the trick.

Related

How to find out list of kernel files compiled by a kernel? [duplicate]

I'm working on different Android projects and need to setup project in Source Insight for different kernel source tree.
There are many unused files in kernel, I want to find a method to pick out all .c,.h,.S files that are compiled in kernel. I was nearly crazy when I pick the source files manually.
I'd wrote a script that can pick up the files corresponding to the .o files, but there are some .o files are compiled by multiple .c files, which make it more complicated.
Is there an easier way to know what files are handled in the compiling process?
Any information would be greatly appreciated.
It's my first question in stackoverflow, I love here so much.
Thanks.
I always need to search the kernel source without looking at powerpc, ia86, sparc, alpha, infiniband, etc. Assuming you can compile the kernel, several ways of doing this:
1) $K/scripts/basic/fixdep.c is called from Makefile.build to create a .cmd file for each source which contains information about the compile options, compile source/target and dependency list. Modify this to write a separate file with just the source file or source/dependencies.
2) Hack $K/scripts/Makefile.build to log the currently compiled file. See the cmd_as_o_S and rule_cc_o_c areas.
Option #1 is the best but requires a little coding. Option #2 is easiest but a true hack, and doesn't pick up the dependencies.

How can I compare .text and .data segments of a .dll against the same ones in a different .dll?

I have a 20+ yo .dll, written in C that none of my colleagues want to touch. With good reason, it uses macros, macro constants and casting EVERYWHERE, making the symbol table quite lean.
Unfortunately, I have to sometimes debug this code and it drives me crazy that it doesn't use something as simple as enums which would put symbols in the .pdb file to make debugging just that little bit easier.
I would love to convert some of the #defines to enums, even if I don't change the variable types as yet, but there is a genuine fear that it will cause possible issues in terms of performance if it were to change the code generated.
I need to show definitively, that no compiled code changes will occur, but it would seem that the .dll is actually changing significantly in a 64 bit build. I looked at one of the function's disassembly code and it appears to be unaffected, but I need to show what is and is not changing in the binary to alleviate the fears of my colleagues as well as some of my own trepidation, plus the bewilderment as to why any changes would propagate to the .dll at all, though the .dlls are of the same size.
Does anyone have any idea how I could do this? I've tried to use dumpbin, but I'm not that familiar with it and am getting some mixed results, prolly because I'm not understanding the output as much as I like.
The way I did this was as follows:
Turn on /FAs switch for project.
Compile that project.
Move the object file directory (Release => Release-without-enums)
Change #defines to enums
Compile that project again.
Move the object file directory (Release => Release-with-enums)
From a bash command line. Use the command from the parent of the Release directory:
for a in Release-without-enum/*.asm; do
git diff --no-index --word-diff --color -U10000 $a "Release-with-enum/$(basename $a)";
done | less -R
The -U10000 is just so that I can see the entire file of each file. Remove it if you just want to see the changes.
This will list all of the modifications in the generated assembly code.
The changes found were as follows:
Symbol addresses were moved about for apparently no reason
Referencing __FILE__ seems to result in not getting a full path when using enums. Why this would translate to removing the full path when using enums is a mystery as the compiler flags have not changed.
Some symbols were renamed for apparently no reason.
Edit
2 and 3 seem to be caused by a corrupted .pdb error. This might be due to the files being used in multiple projects in the same solution. Rebuilding the entire solution fixed those 2 problems.

CLion Indexing in Makefile project

So, I understand that CLion currently only fully supports CMake projects. I don't care if I can't compile or run anything with CLion, as I don't currently do that with Eclipse anyway. I am just looking for editor support, with nice click-to-follow, autocomplete, etc.
What I am wondering is whether or not indexing can still work for non-CMake projects. I can create my project just fine, and indexing completes just fine, but after that is done it can't find my include files. It creates a default CMakeLists.txt file, in which the appropriate sources and include_directories have been added. It doesn't seem to make a difference though, as after indexing completes I still can't click-to-follow #include lines, and any references to things in other files don't work correctly.
Is there something else I can do to make indexing work so I can use CLion as an editor, or is this a pipe dream until Makefile support is someday added?
After some research, I found out your best chances are:
Once it's created, edit CMakeLists.txt (for example, see How to
find libraries). One example:
set(Library "../Library")
include_directories(${Library})
set(SOURCES main.cpp)
add_executable(project_name ${SOURCES})
Note ../ goes to the up folder and in the main.cpp you can use #include "header_to_add.h" (header_to_add.h must be in ../Library folder.
Edit the source code of you .cpp, .h or whatever to add the full path of the library you want to #include taking into account the scope starts in the directory where the file is.
For example: #include "../Library/header_to_add.h" (note the "../" goes one level up from the current folder".
(Maybe not possible or hard) Modify the makefile to prepare CMake to get the necessary inputs (for example, see this).
I recommend the first one mainly because it maintains the structure outside the source files.
Edit: Also it's possible to prepare CMake to use makefile (Source).

How to get a whole list of compiled files of Linux kernel?

I'm working on different Android projects and need to setup project in Source Insight for different kernel source tree.
There are many unused files in kernel, I want to find a method to pick out all .c,.h,.S files that are compiled in kernel. I was nearly crazy when I pick the source files manually.
I'd wrote a script that can pick up the files corresponding to the .o files, but there are some .o files are compiled by multiple .c files, which make it more complicated.
Is there an easier way to know what files are handled in the compiling process?
Any information would be greatly appreciated.
It's my first question in stackoverflow, I love here so much.
Thanks.
I always need to search the kernel source without looking at powerpc, ia86, sparc, alpha, infiniband, etc. Assuming you can compile the kernel, several ways of doing this:
1) $K/scripts/basic/fixdep.c is called from Makefile.build to create a .cmd file for each source which contains information about the compile options, compile source/target and dependency list. Modify this to write a separate file with just the source file or source/dependencies.
2) Hack $K/scripts/Makefile.build to log the currently compiled file. See the cmd_as_o_S and rule_cc_o_c areas.
Option #1 is the best but requires a little coding. Option #2 is easiest but a true hack, and doesn't pick up the dependencies.

OpenGL SDK How To Create New Projects With Premake

I have recently begun the process of learning OpenGL to start making some Graphical applications using C++. I have installed the OpenGL SDK and I am able to build the projects properly on that. However, on the OpenGL SDK site there is little to no information what-so-ever on how to create new projects using the elements of the SDK, such as freeglut etc. I have Premake 4.0 and I understand I have to do something with the lua files, I do not know lua however and am not sure how to use the Lua files to create a new project. So could you help me out? Im using VS2010, should I create the project, then do something with premake? Or create some sort of lua file, then use premake on that? Any help would be wonderful because I am very lost, and would really like to get started with OpenGL. I have experimented a lot with this, such as copying the lua files from the sdk, but that came with no luck.
If you are not familiar with Premake4, then I strongly advise you to just use Visual Studio projects directly. If you're having trouble with that, then please amend your question with exactly what you did, and exactly the error messages that Visual Studio gave you when attempting to build. You should include:
The include paths. The full set of include paths, including full absolute directory names (including the path of your project and solution files).
The static library search paths.
The static libraries you are including.
The defines you are building with.
Note: If you don't know what any of these are, then you need to stop and learn a lot more about how C++ projects work. You need to understand how compilers deal with include paths, static libraries, #defines, etc.
If you are not familiar with Premake4, and you still want to use Premake4 with the SDK, then you first must become familiar with Premake4 without the SDK. I could give you an entire premake4.lua script that you could just plug in, change a few lines, and everything would magically work (and if you want that, you could look at how the SDK's examples are built. Specifically examples/premake4.lua). But if I did that, you wouldn't learn anything. You'd just be copy-and-pasting code, without having the slightest understanding of how it works.
So instead, I'm going to tell you what steps you should take to learn how to use Premake4.
Step 1: Hello World, Premake-style. You should make a single .cpp file that is a Hello World application. It just has a standard main function that prints "Hello World" to the console. That's the easy part.
The hard part is the Premake4 script. Rather than creating a Visual Studio project directly, you are going to write a Premake4 script to build that project for you.
The Premake4 documentation can walk you through the steps of making your first solution and project. You will of course need to add files to that project. You should also learn how to use configurations, so that you can have a Debug and Release build. The Debug build should have symbols, and the Release build should be optimized.
Step 2: Multiple projects. Here, you have two .cpp files: test.cpp and main.cpp. In test.cpp, place a function that prints something. The function shouldn't take parameters or anything. In main.cpp, you should have the main function that calls the function defined in test.cpp. There should also be a test.h which has a prototype for the function defined in test.cpp.
The trick here is that you aren't compiling them into the same executable. Not directly. You want two projects: one named test and one named main. The test project should be a static library, which compiles test.cpp. The main project will be the actual executable, which compiles main.cpp. Both of them should include test.h in their file lists.
Here, you're learning that solutions can have multiple projects. The two projects have different file lists. Each project can have a separate kind, which determines the type of build for that project alone. The test project should be a StaticLib, while the main project should be a ConsoleApp.
You will also need to learn to use the links command to link them together. The main project should use links to specify test. test does not need to link to something.
Step 3: Mastering directories.
Here, you're going to do the same thing as Step 2. Except for one thing: put test.h and test.cpp in a different directory (a subdirectory of the current one). You also want a test.lua file in that directory, which you will execute from your main premake4.lua file with a dofile command. The test.lua is where you define your test project. You can call dofile on the test.lua file anytime after you have created the solution with the solution command.
Note that the main project will need to change the directory where it finds test.h. You will also need to use the includedirs command in the main project to tell the compiler where to search for the test.h header you include in main.cpp.
Step 4: Back to the SDK. At this point, you should now be familiar enough with Premake4 to look back at the instructions I pointed you to and understand them a bit better. Then, just do what the instructions say. When it tells you what the first line of your script should be, make that the first line of your script. Put the UseLibs function where it says to put them; it even gives you an example of where it goes. Think of UseLibs as a fancy combination of links and includedirs.

Resources