Add to include path ( -I ) in Jamroot - bjam

I have a boost iostreams based project and executing
export CPATH=/apps/bzip2/include/
before bjam link=static works. Is there a way to set this in the Jamroot :
project infracore
: requirements
<include>$(PROJECT_ROOT)_install
<include>$(BOOST_INCLUDE_BASE)
<include>$(BZIP2_INCLUDE_BASE) #this does not work it seems
<library>/boost/filesystem//boost_filesystem
<library>/boost/system//boost_system
<library>/boost/date_time//boost_date_time
<library>/boost/iostreams//boost_iostreams
<variant>debug:<inlining>off
<variant>debug:<debug-symbols>on
<variant>debug:<optimization>off
<variant>debug:<warnings>on
<variant>release:<warnings>on
<library-path>/apps/bzip2/lib
<library-path>/apps/zlib/lib
<link>static
;
# Libraries
build-project UtilsCode ;
build-project ProfilerCode ;
build-project CommonDataStructuresCode ;
build-project Math ;
# Executibles
build-project fixfast ;
build-project Tools ;
build-project RiskConsole ; #u2ic

Apologies the error was being reported from the boost installation. Adding does work, except that it needed to be done in the boost Jamroot

Related

Getting the build type/variant inside a bjam Jamfile / echo a feature?

So, let's say, I call bjam debug, or bjam release, or bjam clean, possibly with other target names, and I'd like to have the build action or type (debug, release, clean) available in a script.
Here https://android.googlesource.com/platform/external/boost/+/ac861f8c0f33538060790a8e50701464ca9982d3/Jamroot I found an example, that I modified like this:
import modules ;
tbuildcmd = "" ;
if clean in [ modules.peek : ARGV ]
{
tbuildcmd = clean ;
}
else if release in [ modules.peek : ARGV ]
{
tbuildcmd = release ;
}
else if debug in [ modules.peek : ARGV ]
{
tbuildcmd = debug ;
}
echo "tbuildcmd $(tbuildcmd)" ;
And this works fine, it seems - but I was wondering, is there a better method to get the build command/type as a variable? For instance, they say in https://www.boost.org/doc/libs/1_35_0/doc/html/bbv2/tutorial.html :
The release and debug that we've seen in bjam invocations are just a shorthand way to specify values of the variant feature. For example, the command above could also have been written this way:
bjam variant=release inlining=off debug-symbols=on
So, there is apparently a "variant" "feature" - but how can I use / echo it? I tried echo $(<variant>) and that failed.

Python 3.8.0a3 failed to get the Python codec of the filesystem encoding

When I call the embedded python from my c++ app, the application crashes. Something in _PyCodec_Lookup is not working. Debugging seems to indicate the error comes from this line in file codecs.c:
PyInterpreterState *interp = _PyInterpreterState_GET_UNSAFE();
if (interp->codec_search_path == NULL && _PyCodecRegistry_Init())
goto onError;
interp->codec_search_path is NULL and _PyCodecRegistry_Init() returns -1.
This problems is already known; Solutions like removing python27, or setting environment variables PYTHONPATH or PYTHONHOME to either "" or the src path do not work.
I link to cpython version 3.8.0a3 which I've compiled with the included scripts inside the PCBUILD folder, using the same compiler as my applications (MSVC 15 2017).
The OS is windows 8.1 64 bit.
My application links to the produced binary python38.dll / python38.lib successfully but then crashes at runtime, and I have no idea what might cause the trouble - people suggest the environment is polluted, but it must not depend on the system's environment. How would I confidently ship the app to other people's computers? Did I maybe miss some compile flags or defines?
I'm sure you are, but you are doing this after Py_Initialize ?
I include the python3.8 dll but when starting up I take the executable full
path and then add that to the python path (the code below is not tested but
it's roughly what I do)
void py_add_to_path (const char *path)
{
PyObject *py_cur_path, *py_item;
char *new_path;
int wc_len, i;
wchar_t *wc_new_path;
char *item;
new_path = strdup(path);
py_cur_path = PySys_GetObject("path");
for (i = 0; i < PyList_Size(py_cur_path); i++) {
char *tmp = strappend(new_path, PATHSEP);
myfree(new_path);
new_path = tmp;
py_item = PyList_GetItem(py_cur_path, i);
if (!PyUnicode_Check(py_item)) {
continue;
}
item = py_obj_to_str(py_item);
if (!item) {
continue;
}
tmp = strappend(new_path, item);
free(new_path);
new_path = tmp;
free(item);
}
/* Convert to wide chars. */
wc_len = sizeof(wchar_t) * (strlen(new_path) + 1);
wc_new_path = (wchar_t *) malloc(wc_len, "wchar str");
mbstowcs(wc_new_path, new_path, wc_len);
PySys_SetPath(wc_new_path);
}
Seems a bit old now but looks like there is need to add the Lib folder including all the python system files to the search paths of the application.
Take a look at this Python port for UWP
It has an embedded python34app.zip that includes the codec files.

How to include nmath.h?

I would like to include the header nmath.h for my C code (within an R package) to find R_FINITE and ML_ERR_return_NAN. I found that one cannot include nmath.h directly. For R_FINITE to be found, I could include R_ext/libextern.h. But I don't know what to include so that ML_ERR_return_NAN is found. Any ideas? I found here that Prof. Brian Ripley referred to Writing R Extensions, but I couldn't find nmath.h being addressed there (where exactly?)
On Debian or Ubuntu:
sudo apt-get install r-mathlib
after which you can build test programs such as this:
// -*- mode: C++; c-indent-level: 4; c-basic-offset: 4;
// compile-command: "gcc -s -Wall -O3 \
// -I/usr/share/R/include -o rmath_rnorm \
// rmath_rnorm.c -lRmath -lm" -*-
// Compare to
// $ Rscript -e "RNGkind('Marsaglia'); \
// .Random.seed[2:3] <- c(123L, 456L); rnorm(2)"
// [1] -0.2934974 -0.3343770
#include <stdio.h>
#define MATHLIB_STANDALONE 1
#include <Rmath.h>
int main(void) {
set_seed(123, 456);
printf("rnorm: %f %f\n", rnorm(0.0, 1.0), rnorm(0.0, 1.0));
return 0;
}
Note: The first four lines should be one-line in the file you safe, then M-x compile build the program for your. Ditto for the Rscript invocation: one line.
Edit: Drats. Answered the wrong question :) nmath.h appears to not be exported from src/nmath/nmath.h but this R Mathlibrary is what is exported by R Core for use by others. Where as the nmath.h file has
/* Private header file for use during compilation of Mathlib */
#ifndef MATHLIB_PRIVATE_H
#define MATHLIB_PRIVATE_H
so you are not supposed to rely on it.

How do I determine if a terminal is color-capable?

I would like to change a program to automatically detect whether a terminal is color-capable or not, so when I run said program from within a non-color capable terminal (say M-x shell in (X)Emacs), color is automatically turned off.
I don't want to hardcode the program to detect TERM={emacs,dumb}.
I am thinking that termcap/terminfo should be able to help with this, but so far I've only managed to cobble together this (n)curses-using snippet of code, which fails badly when it can't find the terminal:
#include <stdlib.h>
#include <curses.h>
int main(void) {
int colors=0;
initscr();
start_color();
colors=has_colors() ? 1 : 0;
endwin();
printf(colors ? "YES\n" : "NO\n");
exit(0);
}
I.e. I get this:
$ gcc -Wall -lncurses -o hep hep.c
$ echo $TERM
xterm
$ ./hep
YES
$ export TERM=dumb
$ ./hep
NO
$ export TERM=emacs
$ ./hep
Error opening terminal: emacs.
$
which is... suboptimal.
A friend pointed me towards tput(1), and I cooked up this solution:
#!/bin/sh
# ack-wrapper - use tput to try and detect whether the terminal is
# color-capable, and call ack-grep accordingly.
OPTION='--nocolor'
COLORS=$(tput colors 2> /dev/null)
if [ $? = 0 ] && [ $COLORS -gt 2 ]; then
OPTION=''
fi
exec ack-grep $OPTION "$#"
which works for me. It would be great if I had a way to integrate it into ack, though.
You almost had it, except that you need to use the lower-level curses function setupterm instead of initscr. setupterm just performs enough initialization to read terminfo data, and if you pass in a pointer to an error result value (the last argument) it will return an error value instead of emitting error messages and exiting (the default behavior for initscr).
#include <stdlib.h>
#include <curses.h>
int main(void) {
char *term = getenv("TERM");
int erret = 0;
if (setupterm(NULL, 1, &erret) == ERR) {
char *errmsg = "unknown error";
switch (erret) {
case 1: errmsg = "terminal is hardcopy, cannot be used for curses applications"; break;
case 0: errmsg = "terminal could not be found, or not enough information for curses applications"; break;
case -1: errmsg = "terminfo entry could not be found"; break;
}
printf("Color support for terminal \"%s\" unknown (error %d: %s).\n", term, erret, errmsg);
exit(1);
}
bool colors = has_colors();
printf("Terminal \"%s\" %s colors.\n", term, colors ? "has" : "does not have");
return 0;
}
Additional information about using setupterm is available in the curs_terminfo(3X) man page (x-man-page://3x/curs_terminfo) and Writing Programs with NCURSES.
Look up the terminfo(5) entry for the terminal type and check the Co (max_colors) entry. That's how many colors the terminal supports.

How do you create rules in BJAM?

I would like to compile a file with a specific compiler not supported on boost. I made a rule:
rule my_rule ( source : target )
{
compile_specially source target ;
}
actions compile_specially
{
my_compile_command $(my_parameters) $(1) -o $(2)
}
now this code builds the file into the Jamroot directory (obviously). I, however want it to be build in the regular target path (bin/gcc-4.4/release/threading-multi/...). So how do I get/generate the standard path in my_rule?
Thank You in advance.
Use the "make" target (see BBv2 Custom Commands). Of course this doesn't really get you what I think you are after. What you want is to create a new toolset which is considerably more complicated. You'll want to read through the extender chapter of the documentation. In particular the tools and generators section. And join us in the Boost Build mail list for detailed questions and debugging.
Not exactly what you are asking, but looks similar enough to help. In the example below I compile D language source files using gdc and eventually link them with C libraries (writing my own C functions would need to define interface d modules as d name mangling differs from C ones and would raise linking issues). I followed what is described in tools and generators section (see answer by #GrafikRobot) to achieve this and it was quite easy.
Here is sample jam files and code.
gdc.jam
import type ;
type.register D : d ;
import generators ;
generators.register-standard gdc.compile : D : OBJ ;
actions compile
{
# "echo" $(>) $(<)
"gdc" -c -o $(<) $(>)
}
Jamroot
import gdc ;
project hello
: requirements
<cflags>-O3
: default-build release
;
lib gphobos2 : : <file>/usr/lib/gcc/x86_64-linux-gnu/4.6/libgphobos2.a <name>gphobos2 ;
lib m : : <name>m ;
lib z : : <name>z ;
lib rt : : <name>rt ;
lib pthread : : <name>pthread <link>shared ;
exe hello
:
hello.d
bye.d
gphobos2 m z rt pthread
:
<link>static
;
Hello.d
import std.stdio;
void main()
{
writeln("Hello World!");
static import bye ;
bye.bye();
}
Bye.d
module bye;
import std.stdio;
void bye()
{
writeln("Good bye");
}

Resources