The video tutorial in http://www.kframework.org/index.php/Lesson_4,_LAMBDA:_Generating_Documentation;_Latex_Attributes suggests that we should use kompile lambda --pdf, but when I run it I got the following error:
[Error] Critical: Unknown option: --pdf (Unknown option: --pdf)
The kdoc --help option also result in a Command 'kdoc' not found error.
How do I correctly use this option to generate the formatted K definition?
The kdoc functionality (and --pdf) has not worked for quite some time.
If you want LaTeX ASTs output for given individual terms, you can use --output latex for any of kast, krun, or kprove. Unfortunately this does not work for entire definitions yet, and will not auto-format for you (it only outputs an AST, you'll still need to tell LaTeX how to render the nodes in said AST).
I am trying to build a simple c++ hello world program using g++ with SCons. How can I specify that I want SCons to use g++ without any dependencies on external environment variables, such as PATH?
This is what I've tried:
env = Environment(CXX = 'C:/cygwin/bin/g++')
env.Program('helloworld.c++')
This is my result:
scons: warning: No version of Visual Studio compiler found - C/C++
compilers most likely not set correctly
File "C:\Python27\Scripts\scons.py", line 201, in <module>
C:/cygwin/bin/g++ /Fohelloworld.obj /c helloworld.c++ /TP /nologo
g++: error: /Fohelloworld.obj: No such file or directory
g++: error: /c: No such file or directory
g++: error: /TP: No such file or directory
g++: error: /nologo: No such file or directory
scons: *** [helloworld.obj] Error 1
scons: building terminated because of errors.
Turns out the answer was staring me straight in the face. My first problem was that the first part of this answer:
import os
env = Environment(ENV = {'PATH' : os.environ['PATH']})
utilizes the OS PATH, which I explicitly wanted to avoid. My second problem was that I completely overlooked the answer below, which was the precise answer to my question:
The way to guarantee that the build is repeatable is to explicitly
initialize the PATH
path= ['/bin', '/usr/bin', '/path/to/other/compiler/bin']
env = Environment(ENV = {'PATH' : path})
The reason I didn't realize this was the solution is because I simply misunderstood that env['ENV']['PATH'] and os.environ['PATH'] are completely separate and distinct. Whereas os.environ['PATH'] is obviously the external OS PATH, env['ENV']['PATH'] seems to be SCons' internal equivalent. You can set is to be whatever you please.
In the end, the precise solution I chose, and the one most readable to me was:
PATH = {'PATH' : ['C:/cygwin/bin']}
env = Environment(ENV = PATH)
env['ENV'] = PATH
env['CXX'] = 'g++'
env.Program('helloworld.c++')
A slightly cleaner way
env = Environment(tools=['g++','gnulink'])
env['ENV']['PATH'] = ['C:/cygwin/bin']
env['CXX'] = 'g++'
env.Program('helloworld.c++')
Another way:
env = Environment(tools=['g++','gnulink'])
env.PrependENVPath('PATH','C:/cygwin/bin')
env.Program('helloworld.c++')
Try this:
env = Environment(tools=['ar', 'cc', 'clang', 'clangxx', 'gcc', 'g++', 'gnulink', 'link'], ENV=os.environ, toolpath=['custom_path']).
The command above will:
Create a variable env of type Environment.
Tells scons to set up requires tools.
Find these tools in system variable.
Else find in custom path(you can omit the last parameter: toolpath=['custom_path'] if you don't need it).
Where:
ar: Sets construction variables for the ar library archiver.
Sets: $AR, $ARCOM, $ARFLAGS, $LIBPREFIX, $LIBSUFFIX, $RANLIB, $RANLIBCOM, $RANLIBFLAGS.
cc: Sets construction variables for generic POSIX C compilers.
Sets: $CC, $CCCOM, $CCFLAGS, $CFILESUFFIX, $CFLAGS, $CPPDEFPREFIX, $CPPDEFSUFFIX,$FRAMEWORKPATH, $FRAMEWORKS, $INCPREFIX, $INCSUFFIX, $SHCC, $SHCCCOM, $SHCCFLAGS,$SHCFLAGS, $SHOBJSUFFIX.
clang: Set construction variables for the Clang C compiler.
Sets: $CC, $CCVERSION, $SHCCFLAGS.
clangxx: Set construction variables for the Clang C++ compiler.
Sets: $CXX, $CXXVERSION, $SHCXXFLAGS, $SHOBJSUFFIX,$STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME.
g++: Set construction variables for the gXX C++ compiler.
Sets: $CXX, $CXXVERSION, $SHCXXFLAGS, $SHOBJSUFFIX.
gcc: Set construction variables for the gcc C compiler.
Sets: $CC, $CCVERSION, $SHCCFLAGS.
gnulink: Set construction variables for GNU linker/loader
Sets: $LDMODULEVERSIONFLAGS, $RPATHPREFIX, $RPATHSUFFIX, $SHLIBVERSIONFLAGS,$SHLINKFLAGS, $_LDMODULESONAME, $_SHLIBSONAME.
link: Sets construction variables for generic POSIX linkers. This is a "smart" linker tool which selects a compiler tocomplete the linking based on the types of source files.
Sets: $LDMODULE, $LDMODULECOM, $LDMODULEFLAGS, $LDMODULENOVERSIONSYMLINKS,$LDMODULEPREFIX, $LDMODULESUFFIX, $LDMODULEVERSION, $LDMODULEVERSIONFLAGS,$LIBDIRPREFIX, $LIBDIRSUFFIX, $LIBLINKPREFIX, $LIBLINKSUFFIX, $LINK,$LINKCOM, $LINKFLAGS, $SHLIBSUFFIX, $SHLINK, $SHLINKCOM, $SHLINKFLAGS,$__LDMODULEVERSIONFLAGS, $__SHLIBVERSIONFLAGS.Uses: $LDMODULECOMSTR, $LINKCOMSTR, $SHLINKCOMSTR
Or you can use default config tools for your system by:
env = Environment(tools=['default'], ENV=os.environ)
To quote from scons man 4.1.0
default
Sets construction variables for a default list of Tool modules. Use
default in the tools list to retain the original defaults, since the
tools parameter is treated as a literal statement of the
tools to be made available in that construction environment, not
an addition.
The list of tools selected by default is not static, but
is dependent both on the platform and on the software installed on the
platform. Some tools will not initialize if an underlying command is
not found, and some tools are selected from a list of choices on
a first-found basis. The finished tool list can be examined
by inspecting the TOOLS construction variable in the construction
environment.
On all platforms, all tools from the following list are
selected whose respective conditions are met: filesystem,wix, lex,
yacc, rpcgen, swig, jar, javac, javah, rmic, dvipdf, dvips, gs, tex,
latex, pdflatex, pdftex, tar, zip, textfile.
On Linux systems, the
default tools list selects (first-found): a C compiler from gcc,
intelc, icc, cc; a C++ compilerfrom g++, intelc, icc, cxx; an
assembler from gas, nasm, masm; a linker from gnulink, ilink; a
Fortran compilerfrom gfortran, g77, ifort, ifl, f95, f90, f77; and a
static archiver 'ar'. It also selects all found from the list m4,
rpm.
On Windows systems, the default tools list selects
(first-found): a C compiler from msvc, mingw, gcc, intelc,icl,
icc, cc, bcc32; a C++ compiler from msvc, intelc, icc, g++, cxx,
bcc32; an assembler from masm, nasm, gas,386asm; a linker from mslink,
gnulink, ilink, linkloc, ilink32; a Fortran compiler from gfortran,
g77, ifl, cvf, f95,f90, fortran; and a static archiver from mslib, ar,
tlib; It also selects all found from the list msvs, midl.
On MacOS
systems, the default tools list selects (first-found): a C compiler
from gcc, cc; a C++ compiler from g++, cxx; an assembler 'as'; a
linker from applelink, gnulink; a Fortran compiler from gfortran, f95,
f90, g77; anda static archiver ar. It also selects all found from the
list m4, rpm.
Default lists for other platforms can be found by
examining the scons source code (see SCons/Tool/init.py).
I have managed to build the Kicad 4.0.6 in Linux Mageia 5.1 with gcc version 4.9.2. I first manually fixed two wxWidgets 3.0.2 header files in the /usr/include/wx-3.0/wx/ directory: regex.h and features.h. Kicad then compiled successfully. With the native wx-3.0 headers, the compiler generated the error in pcbnew/netlist_reader.cpp due to the undefined variable wxRE_ADVANCED.
The features.h header checks if the macro WX_NO_REGEX_ADVANCED is defined. If yes, features.h UNdefines wxHAS_REGEX_ADVANCED macro, and defines it, if no. The macro wxHAS_REGEX_ADVANCED, in turn, is used in regex.h to determine if among the enum constants wxRE_ADVANCED = 1 is present. The standard prebuilt Mageia 5 packages wxgtku3.0_0 and lib64wxgtku3.0-devel that I installed with the use of Mageia's software manager urpmi from Mageia repository WX_NO_REGEX_ADVANCED is defined, therefore wxHAS_REGEX_ADVANCED is undefined, and, hence, wxRE_ADVANCED is undefined either. Kicad 4.0.6 source package assumes wxRE_ADVANCED = 1, therefore the build process stops with the error.
Then I reverted /usr/include/wx-3.0/wx/regex.h and features.h to their original state and learned how to add the definition of wxRE_ADVANCED to CMakeLists.txt. However, I still have a question.
The recommended format of adding the definition to CMakeLists.txt I found at CMake command line for C++ #define is this:
if (NOT DEFINED wxRE_ADVANCED)
set(wxRE_ADVANCED 1)
endif()
add_definitions(-DwxRE_ADVANCED=$(wxRE_ADVANCED))
However, it did not work! The macro expansion for wxRE_ADVANCED in pcbnew/netlist_reader.cpp was empty. I printed it at compile time inserting the following lines into the netlist_reader.cpp file (this was hard to find, most of the recommended formats did not work. The correct one is in C preprocessor: expand macro in a #warning):
#define __STRINGIFY(TEXT) #TEXT
#define __WARNING(TEXT) __STRINGIFY(GCC warning TEXT)
#define WARNING(VALUE) __WARNING(__STRINGIFY(wxRE_ADVANCED = VALUE))
Pragma (WARNING(wxRE_ADVANCED))
Finally, I simplified the CMakeLists.txt definition down to this, and it was a success:
if (NOT DEFINED wxRE_ADVANCED)
set(wxRE_ADVANCED 1)
endif()
add_definitions(-DwxRE_ADVANCED=1)
My question: what is the meaning of "-DwxRE_ADVANCED=$(wxRE_ADVANCED)" if it does not work? Is it possible not to use set(wxRE_ADVANCED 1), and simply write add_definitions(-DwxRE_ADVANCED=1)? Thank you.
P.S. Yes, the Kicad 4.0.6 build process successfully finished with only one line added to the top level CMakeLists.txt file:
add_definitions(-DwxRE_ADVANCED=1)
A variable is called via $variable or ${variable}. Note the curly brackets, not parentheses.
Also, it is recommended to use:
target_compile_definitions(mytarget PUBLIC wxRE_ADVANCED=1)
on a target directly, rather than the general add_definitions() command.
I downloaded libblas.dll win32 version, "Prebuilt dynamic libraries using Mingw" from https://icl.cs.utk.edu/lapack-for-windows/lapack/#libraries and used a g77 blas sample "blas3_d_prb.f" from http://people.sc.fsu.edu/~jburkardt/f77_src/blas3_d/blas3_d.html with my g77 compiler, I already tried by converting "libblas.lib" to "libblas.a" with reimp and pexports etc.... but unsuccessful.
I hope anybody have some experience with using libblas.dll with g77(because linking the dll with g77 is seems to be tricky), I also want to confirm calling convention used by "libblas.dll" std or cdecl(what g77 follows)?
Thanks.
I finally determined the problems compiling this particular fortran blas program:
Actuallly you need sources (for blas0.f and blas3_d.f) not the libblas.dll(Since it is unknown which sources they used)
Blas0.f also required for auxiliary functions used e.g. r8mat_test, r8mat_print etc.
Compile each library i.e. blas0.f and blas3_d.f to object file with this command:
g77 -c blas0.f
g77 -c blas3_d.f
This will produce blas0.o, and blas3_d.o object files then you will compile main prog like this: (PS: Replace trime functs in blas3_d_prf.f with len_trim)
G77.EXE blas3_d_prf.f blas0.o blas3_d.o -o yourblas.exe
It will generate yourblas.exe binary for windows.