How can I generate a Syntastic config file using premake? - c

Syntastic is a source code linter plugin for the Vim editor.
It does various syntax and heuristic checks, using external tools. In the case of C and C++ code, this frequently involves running a compiler on the code.
In order to invoke the compiler, Syntastic reads a config file that contains command-line arguments that should be used to invoke the compiler.
Obviously, the "real" compilation in the project is handled by premake but this means there are potentially two sources of truth -- the compiler flags written into the Syntastic config file, and the compiler flags written by premake into the build scripts.
I'd like to resolve this by having premake generate the compiler flags in the Syntastic config file, also.
This seems like a fairly straightforward task with various possible approaches -- generate a fake compiler, invent a pre-build task, etc. But I don't know enough about the innards of premake to know which of these approaches is the right one.
How can I get premake to generate my syntastic.config file?

I looked into a few different kinds of projects under premake5 -- there have been several added to the documentation recently. None of them quite got me there.
The problem is that what I want to do is either "always create the file" or "create the file when the premake5.lua file changes." That makes things difficult, but not totally impossible.
However, the generated file is not an input file for any of the projects, so that apparently pushes it over the edge from difficult to "not possible ATM".
I tried doing what premake calls Custom Build Commands, but this needs the generated file to be a piece of source code it can use to build with. If this isn't the case, apparently the dependency graph breaks and the makefile is generated without a dependency on the file. :(
In order to just get this working, I opted to just regenerate the file all the time using a prebuild command:
prebuildcommands {
"$(SILENT) "
..repo_dir.."etc/write-syntastic-config.sh $(ALL_CFLAGS)"
.." > "
..repo_dir.."etc/syntastic.config"
}
The key value in this is $(ALL_CFLAGS), the variable used by the Makefile generator to hold the stuff I want.
Syntastic's config file and its use of the config file is a bit touchy. It doesn't accept -L and -l options, or perhaps gcc doesn't accept them in whatever mode it is invoked with. Regardless, some filtering is required the args can be used.
Also, syntastic processes the lines looking specifically for -I, which it then handles in a special way: the include paths are treated as either absolute, or relative to the config file.
Finally, syntastic doesn't appear to know about -isystem, another include-directory option for gcc. So that has to be handles differently.
If anyone cares, here's the script I'm using:
etc/write-syntastic-config.sh
#!/bin/bash
set -euo pipefail
IFS=$'\n\t'
PENDING=""
PENDING_DIR=false
printf '# Generated by %s\n' "$(basename "$0")"
CFG_FILE_DIR="$(dirname "$0")"
for ARG in "$#"
do
#printf >&2 "arg=>%s<\\n" "$ARG"
case "$ARG" in
-I| \
-L)
PENDING="$ARG"
PENDING_DIR=true
;;
-isystem)
# -isystem is like -I, except syntastic doesn't know it
printf '%s\n' "$ARG"
PENDING_DIR=true
;;
-I*| \
-L*) PENDING_DIR=true
PENDING="${ARG:0:2}"
ARG="${ARG/#-?/}"
;;& #<-- Resume matching cases (i.e, "goto next case")
*) if $PENDING_DIR
then
ARG="$(realpath -m \
--relative-to "$CFG_FILE_DIR" \
"$ARG")"
fi
case "$PENDING" in
-L) : ignore it ;;
"") printf '%s\n' "$ARG" ;;
*) printf '%s %s\n' "$PENDING" "$ARG" ;;
esac
PENDING=""
PENDING_DIR=false
;;
esac
done
exit 0

Related

How to find all C functions starting with a prefix in a library

For a small test framework, I want to do automatic test discovery. Right now, my plan is that all tests just have a prefix, which could basically be implemented like this
#define TEST(name) void TEST_##name(void)
And be used like this (in different c files)
TEST(one_eq_one) { assert(1 == 1); }
The ugly part is that you would need to list all test-names again in the main function.
Instead of doing that, I want to collect all tests in a library (say lib-my-unit-tests.so) and generate the main function automatically, and then just link the generated main function against the library. All of this internal action can be hidden nicely with cmake.
So, I need a script that does:
1. Write "int main(void) {"
2. For all functions $f starting with 'TEST_' in lib-my-unit-tests.so do
a) write "extern void $f(void);"
b) write "$f();
3. Write "}"
Most parts of that script are easy, but I am unsure how to reliably get a list of all functions starting with the prefix.
On POSIX systems, I can try to parse the output of nm. But here, I am not sure if the names will always be the same (on my MacBook, all names start with an additional '_'). To me, it looks like it might be OS/architecture-dependent which names will be generated for the binary. For windows, I do not yet have an idea on how to do that.
So, my questions are:
Is there a better way to implement test-discovery in C? (maybe something like dlsym)
How do I reliably get a list of all function-names starting with a certain prefix on a MacOS/Linux/Windows
A partial solution for the problem is parsing nm with a regex:
for line in $(nm $1) ; do
# Finds all functions starting with "TEST_" or "_TEST_"
if [[ $line =~ ^_?(TEST_.*)$ ]] ; then
echo "${BASH_REMATCH[1]}"
fi
done
And then a second script consumes this output to generate a c file that calls these functions. Then, cmake calls the second script to create the test executable
add_executable(test-executable generated_source.c)
target_link_libraries(test-executable PRIVATE library_with_test_functions)
add_custom_command(
OUTPUT generated_source.c
COMMAND second_script.sh library_with_test_functions.so > generated_source.c
DEPENDS second_script.sh library_with_test_functions)
I think this works on POSIX systems, but I don't know how to solve it for Windows
You can write a shell script using the nm or objdump utilities to list the symbols, pipe through awk to select the appropriate name and output the desired source lines.

Why does CMake set -no-fat-lto-objects when I enable LTO/IPO?

I'm enabling IPO (inter-procedural optimization) for a C compilation of mine, using CMake:
set_property(TARGET foo PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)
As expected, this causes an -flto compiler flag to be added. However, it also adds -fno-fat-lto-objects: That means that the resulting object file will only have intermediate code, rather than both properly-compiled and intermediate code; and that means that the linker must support my system compiler's intermediate representation and be IPO/LTO-aware.
I didn't ask for -fno-fat-lto-objects, nor did I want it. Can I get CMake to not add this option?
IMNSHO opinion this is a CMake bug... which I have filed as:
https://gitlab.kitware.com/cmake/cmake/-/issues/23136
The developers have simply made the incorrect assumption that this is what people want.
if(CMAKE_C_COMPILER MATCHES "GNU")
set(CMAKE_C_COMPILE_OPTIONS_IPO "-flto")
endif()
How to find it:
Navigate to your CMake installation directory and to Modules, most of the stuff is there.
It's /usr/share/cmake/Modules on my Linux system
Find the string or similar string that you are interested in
on my system, I do:
$ grep fno-fat-lto-objects -r .
./Compiler/GNU.cmake: list(APPEND __lto_flags -fno-fat-lto-objects)
Navigate and inspect the resulting files, the context where the string is used:
# '-flto' introduced since GCC 4.5:
# * https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Option-Summary.html (no)
# * https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/Option-Summary.html (yes)
if(NOT CMAKE_${lang}_COMPILER_VERSION VERSION_LESS 4.5)
set(_CMAKE_${lang}_IPO_MAY_BE_SUPPORTED_BY_COMPILER YES)
set(__lto_flags -flto)
if(NOT CMAKE_${lang}_COMPILER_VERSION VERSION_LESS 4.7)
# '-ffat-lto-objects' introduced since GCC 4.7:
# * https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html (no)
# * https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/Option-Summary.html (yes)
list(APPEND __lto_flags -fno-fat-lto-objects)
endif()
set(CMAKE_${lang}_COMPILE_OPTIONS_IPO ${__lto_flags})
Come up with a workaround to implement custom behavior of such coe.

Reading a set of variables into a Makefile from a C source file?

I have an AVR8 GCC application that can be built with a standard makefile. Because some folks who want to build the application don't want to set up make and such (or have trouble doing so), I also have figured out how to set the project up so it can be compiled from the Arduino IDE as well.
All is working.
But, I normally set some items in the makefile, like the version number and such, but creating the VERSION string in the makefile and passing it as a define into each source file compilation. But, when run from the Arduino IDE, that step is obviously not occurring. So, I have to create a second #define in the Arduino sketch stub to recreate the define.
This means when I update the version, I need to do so in 2 places, in the makefile and in the source file.
The easy option is to simply move the VERSION creation to the source file, where both can use it. And, I'm OK doing that, but
The makefile actually needs the version information, both to create the right filename (think app_v1.2.3.4.bin) and embed the version number into the bin file since it is used by the boot-loader (if requested) to ensure the version the boot-loader flashes is newer than the one already in FLASH. So, if I move the VERSION, RELEASE, MODIFICATION, etc. defines into the C code, I need to find a way to pull them back into the makefile.
I tried using the file read operations in the makefile, but they seem to ignore:
#define VERSION 0
with the prefaced '#' char.
I see there's some options to run sed/awk/etc, in bash, but I don't want to make too many assumptions on the environment, and the makefile currently runs on Windows as well as Unix/Linux without any differences.
I tried a few stack overflow examples, but nothing seems to yield those 4 numbers from any file, .h or otherwise.
I'm OK with creating version.h with just:
#define VERSION 0
#define RELEASE 1
#define MODIFICATION 2
#define FIX 4
If I can read it into the makefile and create the variables I need.
Jim
You may take a look at gmtt which was designed exactly with you use case in mind. In gmtt the following should read and analyze your header file:
include gmtt.mk
# create a 3-column table from the header file. The first column is just the "#define"
VNR_TABLE := 3 $(file < version.h)
# Extract the values from the table: select column 3 from VNR_TABLE where column 2 equals a string constant.
# Be careful not to introduce spaces in the compare!
VER := $(call select,3,$(VNR_TABLE),$$(call str-eq,$$2,VERSION))
REL := $(call select,3,$(VNR_TABLE),$$(call str-eq,$$2,RELEASE))
MODF := $(call select,3,$(VNR_TABLE),$$(call str-eq,$$2,MODIFICATION))
FIX := $(call select,3,$(VNR_TABLE),$$(call str-eq,$$2,FIX))
I couldn't test it but I think you get the idea.
PS: using a GNUmake library just means placing the included file alongside the makefile.
I think in this case you can use the ‘file’ function of makefiles.
It allows you to write (with > specifier) or read (with < specifier) to/from files. Then you can trim (with filter-out) your variables inside your makefile.
Source: https://www.gnu.org/software/make/manual/html_node/File-Function.html#File-Function
You can use GNU make's $(shell ...) function to extract the macro expansions. Assuming VERSION is defined in src.c and tokens are delimited by spaces (not tabs):
VERSION := $(shell sed -n -e "s/^\#define VERSION *\(.*\)/\1/p" src.c)
.PHONY: all
all:
#echo VERSION=$(VERSION)

Using pg_config with waf

I use waf as my build system and I want to compile a small C program using Postgres. I have included postgres.h in my program so I need to find the path to it in my wscript file. I know that I can get the path I need by running:
pg_config --includedir-server
which gives me:
/usr/include/postgresql/9.3/server
So I thought I could use something like this:
cfg.check_cfg(
path='pg_config',
package='',
uselib_store='PG',
args='--includedir-server',
)
And then build my program by:
bld.program(
source=['testpg.c'],
target='testpg',
includes=['.', '../src'],
use=['PQ', 'PG'],
)
But this fails with postgres.h: No such file or directory. I ran ./waf -v and confirmed that the proper -I flag is not being passed to gcc. My guess is this happens because pg_config does not add a -I prefix to the path it returns. Is there a way I can make waf to add the prefix, or make pg_config to add it?
Should pg_config had the standard output of pkg_config like programs (ie outputs something like -Ixxx -Iyyy), your code would work, has check_cfg parse this kind of output.
As there is no complicated parsing, you can go for:
import subprocess
includes = subprocess.check_output(["pg_config", "--includedir-server"])
includes.replace("\n", "")
conf.env.INCLUDES_PG = [includes]
And then use it:
bld.program(
source=['testpg.c'],
target='testpg',
use=['PG'],
)
See the library integration in the waf book. It explains the naming rule that make it works.
You can write a small plugin to ease the use :)

Trouble building gcc-4.3.4 in a non-standard location

I need to build gcc-4.3.4 in a non-standard location (NFS mounted). I configured:
../gcc-4.3.4/configure --prefix={install dir} --with-gmp={install dir} --with-mpfr={install dir} --with-local-prefix={install dir} --disable-shared
I ran make -j1. But I keep getting:
checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile
In x86_64-unknown-linux-gnu/libgcc/config.log, I can see:
/home/panthdev/apps/gcc-4.3.4-compliant/compiler/objdir/./gcc/cc1: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or directory
libmpfr.so.1 is there in {install dir}/lib. Also if I set LD_LIBRARY_PATH to {install dir}/lib, then it finds the libmpfr.so.1 but config.log starts complaining:
/tmp/cce9YhFK.s: Assembler messages:
/tmp/cce9YhFK.s:16: Error: bad register name `%rbp'
/tmp/cce9YhFK.s:18: Error: bad register name `%rsp'
As I read here you have 32bit binutils where as gcc is trying to do a 64bit build. Make sure your binutils & gcc has the same configuration.
You should maybe try using --with-sysroot instead of --prefix.
In the GCC 4.5.2 configure script (I have that available, but not 4.3.4), at around line 4500 (of 15.5K lines), there is the stanza:
rm -f conftest.$ac_ext
EXEEXT=$ac_cv_exeext
ac_exeext=$EXEEXT
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of object files" >&5
$as_echo_n "checking for suffix of object files... " >&6; }
if test "${ac_cv_objext+set}" = set; then :
$as_echo_n "(cached) " >&6
else
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
int
main ()
{
;
return 0;
}
_ACEOF
rm -f conftest.o conftest.obj
if { { ac_try="$ac_compile"
case "(($ac_try" in
*\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
*) ac_try_echo=$ac_try;;
esac
eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
$as_echo "$ac_try_echo"; } >&5
(eval "$ac_compile") 2>&5
ac_status=$?
$as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
test $ac_status = 0; }; then :
for ac_file in conftest.o conftest.obj conftest.*; do
test -f "$ac_file" || continue;
case $ac_file in
*.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map | *.inf | *.dSYM ) ;;
*) ac_cv_objext=`expr "$ac_file" : '.*\.\(.*\)'`
break;;
esac
done
else
$as_echo "$as_me: failed program was:" >&5
sed 's/^/| /' conftest.$ac_ext >&5
{ { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
as_fn_error "cannot compute suffix of object files: cannot compile
See \`config.log' for more details." "$LINENO" 5; }
fi
rm -f conftest.$ac_cv_objext conftest.$ac_ext
fi
Basically, the script is trying to compile 'conftest.c' and trying to find the extension of the object file created - and, for some reason, your compiler is not creating a conftest.o.
This isn't the first test it does on the compiler, so there seems to be something rather odd going on in your environment.
I've built GCC numerous times over the years - on Solaris and MacOS X - and I've always used the --prefix option. That is not the problem. The GMP, MPFR, MPC directories are necessary; the only option you've used that I'm not familiar with is the --with-local-prefix.
Are you specifying the bootstrap compiler somehow? Consider trying your current configure line with the addition of CC=/usr/bin/gcc or something similar, identifying a fully working compiler on your machine. I'm not convinced that'll solve the problem, but there is something funny about the way the compiler is behaving, or about the object file extensions that it produces. I assume you have several GB of spare space on the disk system? You'll need that.
Poking around the 'Installing GCC: Configuration' page, I find:
--with-local-prefix=dirname
Specify the installation directory for local include files. The default is /usr/local. Specify this option if you want the compiler to search directory dirname/include for locally installed header files instead of /usr/local/include.
You should specify --with-local-prefix only if your site has a different convention (not /usr/local) for where to put site-specific files.
The default value for --with-local-prefix is /usr/local regardless of the value of --prefix. Specifying --prefix has no effect on which directory GCC searches for local header files. This may seem counterintuitive, but actually it is logical.
The purpose of --prefix is to specify where to install GCC. The local header files in /usr/local/include—if you put any in that directory—are not part of GCC. They are part of other programs—perhaps many others. (GCC installs its own header files in another directory which is based on the --prefix value.)
Both the local-prefix include directory and the GCC-prefix include directory are part of GCC's “system include” directories. Although these two directories are not fixed, they need to be searched in the proper order for the correct processing of the include_next directive. The local-prefix include directory is searched before the GCC-prefix include directory. Another characteristic of system include directories is that pedantic warnings are turned off for headers in these directories.
Some autoconf macros add -I directory options to the compiler command line, to ensure that directories containing installed packages' headers are searched. When directory is one of GCC's system include directories, GCC will ignore the option so that system directories continue to be processed in the correct order. This may result in a search order different from what was specified but the directory will still be searched.
GCC automatically searches for ordinary libraries using GCC_EXEC_PREFIX. Thus, when the same installation prefix is used for both GCC and packages, GCC will automatically search for both headers and libraries. This provides a configuration that is easy to use. GCC behaves in a manner similar to that when it is installed as a system compiler in /usr.
Sites that need to install multiple versions of GCC may not want to use the above simple configuration. It is possible to use the --program-prefix, --program-suffix and --program-transform-name options to install multiple versions into a single directory, but it may be simpler to use different prefixes and the --with-local-prefix option to specify the location of the site-specific files for each version. It will then be necessary for users to specify explicitly the location of local site libraries (e.g., with LIBRARY_PATH).
The same value can be used for both --with-local-prefix and --prefix provided it is not /usr. This can be used to avoid the default search of /usr/local/include.
Do not specify /usr as the --with-local-prefix! The directory you use for --with-local-prefix must not contain any of the system's standard header files. If it did contain them, certain programs would be miscompiled (including GNU Emacs, on certain targets), because this would override and nullify the header file corrections made by the fixincludes script.
Indications are that people who use this option use it based on mistaken ideas of what it is for. People use it as if it specified where to install part of GCC. Perhaps they make this assumption because installing GCC creates the directory.
Are you sure you're using that correctly? You probably are since you have to search to find the option -- ../gcc-4.x.y/configure --help does not mention the option.

Resources