I'm using scons as my build system and I'd like to install my project's development headers using scons as well. I'd like to avoid maintaining a list of all the needed headers and their include dependencies and instead use the built-in dependency parsing magic of scons to provide this list for me.
As an example I have 2 headers I want to install, explicitly, Foo1.h and Foo2.h:
/* Foo1.h */
#ifndef FOO1_H_
#define FOO1_H_
#include "Bar.h"
#include <somelibrary.h>
/* header contents */
#endif /* FOO1_H_ */
and
/* Foo2.h */
#ifndef FOO2_H_
#define FOO2_H_
/* header contents */
#endif /* FOO2_H_ */
Since Bar.h is required by Foo1.h, I want it to be installed too, automagically. somelibrary.h shouldn't be part of the installed headers. There has to be some way to accomplish this or there has to be some reason what I'm trying to do isn't advisable.
Thanks for any help!
Well, I figured out the answer. Here's the code snippet that'll do exactly what I was talking about:
def getDependentIncludes(environ, explicit_includes, search_path, depincludes):
for inc in explicit_includes:
if inc not in depincludes:
depincludes.add(inc)
incs = SCons.Defaults.CScan(inc, environ, search_path)
getDependentIncludes(environ, incs, search_path, depincludes)
# create a set of all the headers
development_headers = set()
# call function, with development_headers storing the result
getDependentIncludes(env,
external_facing_headers,
include_dirs, development_headers)
# print the glorious results
names = map(lambda x : '"./' + os.path.relpath(str(x), Dir("#").abspath) + '"', development_headers)
names.sort()
print " ".join(names)
Related
I'm new to cmake, so correct me if I've messed things up and this should be solved using something other than cmake.
I have main_program, that requires multiple other subprograms in form of bindata to be specified at build phase. Right now I build it by running
cmake -DBINDATA1="\xde\xad..." -DBINDATA2="\xbe\xef" -DBINDATA3="..."
and in code I use them as:
// main_program.cpp
int main() {
#ifdef BINDATA1
perform_action1(BINDATA1);
#endif
#ifdef BINDATA2
perform_action2(BINDATA2);
#endif
[...]
This is rather unclean method as any time I'm changing one of subprograms I have to generate bindata from it and pass it to cmake command.
What I would like to do, is have a project structure:
/
-> main_program
-> subprograms
-> subprogram1
-> subprogram2
-> subprogram3
and when I run cmake, I would like to
compile each of subprograms
generate shellcode from each of them, by running generate_bindata program on them
build main_program passing bindatas from step 2
and when I run cmake, I would like to
compile each of subprograms
generate shellcode from each of them, by running generate_shellcode program on them
build main_program passing shellcodes from step 2
Then let's do that. Let's first write a short script to generate a header:
#!/bin/sh
# ./custom_script.sh
# TODO: Find out proper quoting and add `"` is necessarily. Ie. details.
# Prefer to use actual real variables like `static const char *shellcode[3]`
# instead of raw macro defines.
cat > "$1" <<EOF
#define SHELLCODE1 $(cat "$2")
#define SHELLCODE2 $(cat "$3")
#define SHELLCODE3 $(cat "$4")
EOF
To be portable, write this script in cmake. This script will be run at build phase to generate the header needed for compilation. Then, "model dependencies" - find out what depends on what exactly. Then write it in cmake:
add_executable(subprogram1 sources.c...)
add_executable(subprogram2 sources.c...)
add_executable(subprogram3 sources.c...)
for(i IN ITEMS 1 2 3)
add_custom_target(
COMMENT Generate shellcode${i}.txt with the content of shellcode
# TODO: redirection in COMMAND should be removed, or the command
# should be wrapped in `sh -c ...`.
COMMAND $<TARGET_FILE:subprogram${i}> | generate_shellcode > ${CMAKE_CURRENT_BINARY_DIR}/shellcode${i}.txt
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/shellcode${i}.txt
DEPENDS $<TARGET_FILE:subprogram${i}> generate_shellcode
)
endfor()
add_custom_command(
COMMENT Generate shellcodes.h from shellcode1.txt shellcode2.txt and shellcode3.txt
COMMAND sh custom_script.sh
${CMAKE_CURRENT_BINARY_DIR}/shellcodes.h
${CMAKE_CURRENT_BINARY_DIR}/shellcode1.txt
${CMAKE_CURRENT_BINARY_DIR}/shellcode2.txt
${CMAKE_CURRENT_BINARY_DIR}/shellcode3.txt
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/shellcodes.h
DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/shellcode1.txt
${CMAKE_CURRENT_BINARY_DIR}/shellcode2.txt
${CMAKE_CURRENT_BINARY_DIR}/shellcode3.txt
)
# Then compile the final executable
add_executable(main main.c ${CMAKE_CURRENT_BINARY_DIR}/shellcodes.h)
# Don't forget to add includes!
target_include_directories(main PUBLIC ${CMAKE_CURRENT_BINARY_DIR})
# or you may add dependency to a single file instead of target
# Like below only to a single shellcodeswrapper.c file only
# This should help build parallelization.
set_source_files_properties(main.c OBJECT_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/shellcodes.h)
# Or you may add a target for shelcodes header file and depend on it
add_custom_target(shellcodes DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/shellcodes.h)
add_executable(main main.c)
target_include_directories(main PUBLIC ${CMAKE_CURRENT_BINARY_DIR})
add_dependencies(main shellcodes)
Then your main file:
#include <shellcodes.h> // compiler will find it in BINARY_DIR
int main() {
perform_action1(SHELLCODE1);
perform_action2(SHELLCODE2);
}
So that all your source files are not recompiled each time, I suggest to write a wrapper:
// shellcodewrapper.c
#include <shellcodes.h>
// preserve memory by not duplicating code in each TU
static const char shellcode1[] = SHELLCODE1;
// only this file will be recompiled when SHELLCODE changes
const char *get_shellcode1(void) {
return shellcode1;
}
// shellcodewrapper.h
const char *get_shellcode1(void);
// main.c
#include <shellcodewrapper.h>
int main() {
perform_action1(get_shellcode1());
perform_action2(get_shellcode2());
}
That way when you change the "SHELLCODE" generators, only shellcodewrapper.c will be compiled, resulting in super fast compilation times.
Note how dependency is transferred and how it works - I used files inside BINARY_DIR to transfer result from one command to another, then these files track what was changed and transfer dependency below in the chain. Track dependencies in DEPENDS and OUTPUT in add_custom_command and cmake will properly compile in proper order.
I want to compile source codes but I need to add extern "C" to a lot of header files from other package. So I have to keep those intact at the same time.
What I am wondering is, can I add
#ifdef __cplusplus
extern "C" {
#endif
at the header and
#ifdef __cplusplus
}
#endif
to the footer for every header I am interested in?
What I can think of is passing those files to the compiler using $awk but I cannot come up with the details.
Is there any known examples or something I can dig in?
Thank you very much.
You can create wrappers instead that include the headers in question like this:
extern "C" {
#include "header.h"
}
In your own code, you then include the wrappers, not the original headers.
You can automate the creation of those wrapper headers with a one-time script, which should be straightforward. In Bash, for example, I'd just do something like:
for f in include/*; do echo -e "extern \"C\" {\n#include \""$f"\"\n}" > "include_wrappers/wrap_$f"; done
I was surprised to discover that apparently it is not possible to import C predefined macros inside the resource files (.rc) because Resource Compiler is not able to deal with them.
I was trying to put the version information inside a version.h that would be generated / updated by the build system. This file was supposed to be included from the resource.rc so when you build the resources you will always get the same versions across all the built files.
It seems that this has something to do with RC_INVOKED and this bug http://connect.microsoft.com/VisualStudio/feedback/details/532929/rc4011-warnings-from-vc10-rc -- which is closed as "as-designed".
How can I solve this problem?
Is the only option to patch the final exe in order to update the version information? ... I would prefer not do to this and use a more standard way for this.
The resource compiler deals just fine with includes and preprocessor definitions. It just does not deal well with including Windows.h for instance. But I cannot think of any good reason why you'd need that in a file that gets consumed by the resource compiler. Just use a header file that does not include anything causing the warning, and just define what you need. As an example the typical versioning we use here does this and works great: there's a single master .rc file with that looks something like this:
#include <winver.h>
#define stringize( x ) stringizei( x )
#define stringizei( x ) #x
#ifdef VRC_INCLUDE
#include stringize( VRC_INCLUDE )
#endif
#ifdef _WIN32
LANGUAGE 0x9,0x1
#pragma code_page( 1252 )
#endif
1 VERSIONINFO
FILEVERSION VRC_FILEVERSION
PRODUCTVERSION VRC_PRODUCTVERSION
FILEFLAGSMASK 0x1L
FILEFLAGS VS_FF_DEBUG
FILEOS VOS__WINDOWS32
FILETYPE VRC_FILETYPE
BEGIN
BLOCK "StringFileInfo"
BEGIN
BLOCK "040904E4"
BEGIN
VALUE "CompanyName", stringize( VRC_COMPANYNAME )
VALUE "FileDescription", stringize( VRC_FILEDESCRIPTION )
VALUE "FileVersion", stringize( VRC_FILEVERSION )
VALUE "LegalCopyright", stringize( VRC_COPYRIGHT )
VALUE "InternalName", stringize( VRC_ORIGINALFILENAME )
VALUE "OriginalFilename", stringize( VRC_ORIGINALFILENAME )
VALUE "ProductName", stringize( VRC_PRODUCTNAME )
VALUE "ProductVersion", stringize( VRC_PRODUCTVERSION )
END
END
BLOCK "VarFileInfo"
BEGIN
VALUE "Translation", 0x409, 1200
END
END
From here on the possibilities are pretty much unlimited. Either define VRC_INCLUDE to the full path of an include file containing all the VRC_... definitions:
rc /d VRC_INCLUDE=$(VersionMainInclude) ... version.rc
or supply all definitions
rc /d VRC_COMPANYNAME=mycompany ... version.rc
or a combination of both.
To show you the possibilities, here's what I'm currently doing for all projects versioned with git:
every project has a version.h #defining just a short VRC_FILEDESCRIPTION and VRC_FILEVERSION
there's a master version.h #defining VRC_COMPANYNAME/VRC_COPYRIGHT/...
the project includes a .targets file that creates a version.res in a prebuild event
the msbuild prebuild event takes care of the interesting stuff: it creates a new temporary header file combining the other two, takes the short git SHA and the current data and appends that to the file description string so it ends up looking like
Foo Dll [12e454re 30/07/2013]
Added #define _WINSOCKAPI_ but still the build is failing.
/*
* $PostgreSQL: pgsql/src/include/port/win32/sys/socket.h,v 1.7 2006/10/04 00:30:10 momjian Exp $
*/
#ifndef WIN32_SYS_SOCKET_H
#define WIN32_SYS_SOCKET_H
/*
* Unfortunately, <wingdi.h> of VC++ also defines ERROR.
* To avoid the conflict, we include <windows.h> here and undefine ERROR
* immediately.
*
* Note: Don't include <wingdi.h> directly. It causes compile errors.
*/
#define _WINSOCKAPI_ //added this line but no help
#include <winsock2.h>
#include <ws2tcpip.h>
#include <windows.h>
#undef ERROR
#undef small
/* Restore old ERROR value */
#ifdef PGERROR
#define ERROR PGERROR
#endif
/*
* we can't use the windows gai_strerror{AW} functions because
* they are defined inline in the MS header files. So we'll use our
* own
*/
#undef gai_strerror
#endif /* WIN32_SYS_SOCKET_H */
You are trying to compile a Windows-specific header file on a platform that is decidedly not Windows. I can't imagine what you expect this to do; whatever it is, though, it doesn't.
Try using
#ifndef __APPLE__ ... #endif
Then, check out the other compile errors and include apple specific socket files, that also work under BSD socket.
I have tested a bit of assembler on Linux using the AT&T syntax. One thing that struck me was that the book I was reading was written from a 32-bit standpoint. Thus, all sizes would have to be changed to the correct 64-bit versions for me. Or I could (which I did) assemble the code using the --32 flag for as and the -melf_i386 flag for ld when linking. I have also adapted some of the code and to run on Windows under Cygwin.
But that got me thinking. Is there a way to do ifdef like checks in assembler to do one thing if I'm on Windows and another under Linux and also handle 32 vs 64 bit that way? For example to have a .globl _start under Linux and a .globl _main under Windows.
Or is this handled by checking before assembling and having different source files to assemble based on the result of the checks?
I.e. foo_linux.s and foo_windows.s
If so, how do you overcome that fact that you will not know which .s files you will use, and thus have to include, when you are creating your program?
For example, say that we have a socket_linux.s and a socket_windows.s. They both present an identical interface but do the OS specific work associated to sockets. But when I work with the sockets in my program I will not know if I need the Windows or Linux version included. So I would be kinda screwed :)
So how is this handled in Assembler? In C++ for example I could include my socket.h and socket.cpp and wrap all the Linux and Windows specific code in #ifdef statements.
If you use GCC to compile your files and name them .S (with uppercase S) or .sx, it will pass them through the preprocessor before invoking the assembler.
From the docs:
file.s
Assembler code.
file.S
file.sx
Assembler code which must be preprocessed.
You can add -v to the command line to see how the various sub-processes are invoked.
in MASM (.asm), you can use ifdef, ifndef and the likes, as:
ifdef X64
endif
When writing for different platforms you can define some macro for loading target specific files:
FILE target.h
#if defined(__arm__)
#define target "arm"
#elif defined(__x86_64__)
#if defined(_WIN64)
#define target "win64"
#else
#define target "linux64" // all non-Win share the same calling convention
#endif
#else
// 32bit defs
#endif
Then you can include target specific files with the macro, two string literals successively get one single literal:
#include "target.h"
#include "target_specific_code_" target ".h"
It includes one of these files:
target_specific_code_arm.h
target_specific_code_win64.h
target_specific_code_linux64.h
...
EDIT:
Like this, you can also define target specific assembler instructions for later use in inline assembly:
#ifdef ...
#define ASM_PP_LOAD_WORD "movi "
#else
#define ASM_PP_LOAD_WORD "mov "
#endif
or as macro
#ifdef ...
// when using intel assembler there is a different
// order of parameters
#define ASM_PP_LOAD_WORD(a, b) "movi " #b ", " #a
#else
#define ASM_PP_LOAD_WORD(a, b) "mov " #a ", " #b
#endif