I have installed the MinGW cross compiler in Linux, but I'm not able to create i386mingw32msvc-g++ because of which I'm not able to cross compile my C++ application. What has to be done to create it?
In /usr/local/cross-tools/bin, I've all these executables,
i386-mingw32-addr2line
i386-mingw32-ar
i386-mingw32-as
i386-mingw32-gcc
i386-mingw32-gcc-3.4.2
i386-mingw32-gccbug
i386-mingw32-c++filt
i386-mingw32-cpp
i386-mingw32-size
etc.
but not i386mingw32msvc-g++
How do I create it in bin?
Just use i386-mingw32-g++ & friends as i386-mingw32msvc-g++ etc - e.g. alias. They are for all intent and purpose the same thing.
Related
In package development, each example requires <5s. However, the pair of stan_model() and rstan::sampling() take long times more than 5s as follows:
Examples with CPU or elapsed time > 5s
user system elapsed
fit 1.25 0.11 32.47
So I put \donttest{} for each rstan::sampling() in roxygen comments #'#examples
In examples#'#examples, we should not run sampling() or is there any treatment ?
I had tried to create my package based on the code rstan_package_skeleton(path = 'BayesianAAA') when I was taught from you (Thank you !!) but, I do not understand many things about it.
Previously, rstan_package_skeleton(path = 'BayesianAAA') launched the errors in my computer ( but now the error does not occur).
So, I made my package without the rstan_package_skeleton(), say BayesianAAA, and in my original making, I put the Model_A.stan,Model_B.stan,Model_C.stan,.... in the inst/extdata and I refer my stan files as follows;
scr <- system.file("extdata", "Model_A.stan", package="BayesianAAA")
scr <- rstan::stan_model(scr)
I have many questions about the code rstan_package_skeleton(path = 'BayesianAAA').
1) The first question is How to include my existing stan files and how to refer my .stan files for the rstan::stan_model() ?
According to the page following page, it said that
If we had existing .stan files to include with the package we could use the optional stan_files argument to rstan_package_skeleton to include them.
So, I think I should execute, I am not sure but the following like manner is required;
`rstan_package_skeleton(path = 'BayesianAAA', stan_files = "Model_A.stan" )`.
But I do not know how to write the code for several stan files, say Model_A.stan,Model_B.stan,Model_C.stan in my existing package made without the rstan_package_skeleton(). I do not understand , but the following code is correct ? Since I do not where the files described in the variable stan_files is reflected in the new project created by the rstan_package_skeleton().
`rstan_package_skeleton(path = 'BayesianAAA', stan_files = c("Model_A.stan",`Model_B.stan`,`Model_C.stan` )`.
Here, the another question arise, that is,
2) The second question: Where I execute the code rstan_package_skeleton(path = 'BayesianAAA', stan_files = "Model_A.stan" ) ? I execute it form the R studio console in my existing package project. Is it correct ? And then, the new project arise and it is contained the old existing project. What should I do ?
https://cran.r-project.org/web/packages/rstantools/vignettes/minimal-rstan-package.html
3) I do not quite know about the packages "rstanarm" , but I try to imitate it for my package, but I can not fined any .stan file in it, I am wrong ?
I am sorry for my poor English, and Lack of study about these things.
I would be grateful if you could tell me.
You generally should not be writing a package that calls stan_model at runtime, unless like brms or tmbstan you are generating a Stan program at runtime as opposed to writing it statically. There are dozens of packages on CRAN that provide compiled Stan programs basically by following the build process developed for rstanarm, which is facilitated by the rstantools::rstan_package.skeleton function, the step-by-step guide, and the developer guidelines which directly address your question
CRAN policy permits long installation times but imposes restrictions on the time consumed by examples and unit tests that are much shorter than the time that it takes to compile even a simple Stan program. Thus, it is only possible to adequately test your package if it has pre-compiled Stan programs.
Even then, it can be difficult to sample from a posterior distribution (adequately) in five seconds, so you often have to use small datasets, one chain, a small number of iterations, etc.
It is best to pass the names of your Stan programs (which should end in a .stan extension, not use a period otherwise, and only have ASCII letters, numbers, and the underscore in their names) to rstantools::rstan_package_skeleton(). If doing so from RStudio, I would call it while not in an existing project. Then
During installation, all Stan programs will be compiled and saved in the list stanmodels that can then be used by R function in the package. The rule is that the Stan program compiled from the model code in src/stan_files/foo.stan is stored as list element stanmodels$foo.
There are dozens of R packages that have Stan programs in their src/stan_files directory (although the locations of the Stan programs are going to move to inst/stan for the next rstantools release) that for the most part just followed the vignettes and did not have to do any additional steps except write more R functions.
For a specific project I am moving out of qmake and now have to use cmake.
My path are the following:
Source : ~/Projects/Project
External static library (OSVR in this instance) paths : ~/osvr/lib/ , ~/osvr/include/osvr /osvr/include/jsoncpp
Using qmake, the linking part to that library used to be:
INCLUDEPATH += /usr/include
LIBS += -L$$PWD/../../osvr/lib/ -losvrClientKit -losvrClient -losvrCommon -losvrUtil -ljsoncpp
INCLUDEPATH += $$PWD/../../osvr/include/
INCLUDEPATH += $$PWD/../../jsoncpp/include/
DEPENDPATH += $$PWD/../../osvr/lib/
Now I need to use cmake, but the library is not linked to:
The relevant part of my cmake.txt:
set(OSVR_DIR /home/pilou/osvr)
set(OSVR_INCLUDE_DIR /home/pilou/osvr/include/osvr/ClientKit)
find_library(OSVR_LIBRARIES ${OSVR_DIR}/lib)
[...]
target_link_libraries(myexec ${QT_LIBRARIES} ${OSVR_LIBRARIES} )
target_include_directories(myexec PUBLIC include ${OSVR_DIR}/include )
Which doesn't work...
A little help would be lovely as I am not too sure about how:
to ensure the external include folder is scanned
to link to my 3 libraries osvrClientKit osvrClient osvrCommon.
As a matter of fact I am also interested in a good explanation.
Thanks in advance.
EDIT : Thanks to the reply from ComicSansMs and for the posterity, the working Cmake syntax :
set(OSVR_DIR /home/pilou/osvr)
set(OSVR_INCLUDE_DIR /home/pilou/osvr/include)
find_library(OSVR_CLIENT_KIT_LIBRARY osvrClientKit HINTS ${OSVR_DIR}/lib)
find_library(OSVR_CLIENT_LIBRARY osvrClient HINTS ${OSVR_DIR}/lib)
find_library(OSVR_COMMON_LIBRARY osvrCommon HINTS ${OSVR_DIR}/lib)
find_library(OSVR_UTIL_LIBRARY osvrUtil HINTS ${OSVR_DIR}/lib)
find_library(JSONCPP_LIBRARY jsoncpp HINTS ${OSVR_DIR}/lib/x86_64-linux-gnu)
set(OSVR_LIBRARIES ${OSVR_CLIENT_KIT_LIBRARY} ${OSVR_CLIENT_LIBRARY} ${OSVR_COMMON_LIBRARY} ${OSVR_UTIL_LIBRARY} ${JSONCPP_LIBRARY})
and down the track:
target_link_libraries(myExec ${QT_LIBRARIES} ${OSVR_LIBRARIES} )
target_include_directories(myExec PUBLIC include ${OSVR_INCLUDE_DIR} )
Your use of find_library looks wrong.
Check out the manpage for find_library. You have to give the name of the library you want to find as an argument. You can optionally provide additional hints where to find that library:
find_library(OSVR_COMMON_LIBRARY osvrCommon
HINTS ${OSVR_DIR}/lib)
Note that you will need one separate find_library call for each library! Since your libraries seem to have interdependencies, the correct way to model them in CMake is to also add an imported target per library and then model the interdependencies on those targets correctly.
If you don't feel comfortable doing that yet, you can also add all the find libraries to a single OSVR_LIBRARIES variable in the correct order and then depend on that:
find_package(OSVR_COMMON_LIBRARY ...)
find_package(OSVR_CLIENT_LIBRARY ...)
find_package(OSVR_CLIENTKIT_LIBRARY ...)
...
set(OSVR_LIBRARIES ${OSVR_CLIENTKIT_LIBRARY} ${OSVR_CLIENT_LIBRARY} ${OSVR_COMMON_LIBRARY} ...)
target_link_libraries(myexec ${QT_LIBRARIES} ${OSVR_LIBRARIES})
Note though that this approach is quite fragile with regards to future changes and should in general be avoided in favor of the imported targets.
Also, be sure that you actually have proper error handling mechanisms in place for the case that your find calls do not actually find anything.
I've already asked a similar question, here:
Linking to modules in external directory Compaq Visual Fortran command prompt
And I thought that the first answer was correct (that is, in the manual they say you can simply specify the path name before the module), but after deleting the temporary files in my library folder, this approach seemed to stop working. Trying with the /include[:path] approach, here is my .bat file:
df /include:..\FORTRAN_LIB\ __constants
myIO griddata_mod myfdgen myDiff magneticField /exe:magneticField
And an error is returned saying:
__constants
myIO
griddata_mod
myfdgen
myDiff
magneticField
f90: Severe: No such file or directory
... file is '__constants'
Again, I apologize that this question is VERY specific, but it seems like it should be simple and does not work at all.
p.s. Originally, I was using:
df ..\FORTRAN_LIB\__constants ..\FORTRAN_LIB\myIO
..\FORTRAN_LIB\griddata_mod ..\FORTRAN_LIB\myfdgen
..\FORTRAN_LIB\myDiff magneticField /exe:magneticField
But, as I've said, it stopped working after I deleted the temporary files in my FORTRAN_LIB folder. Also note, these .bat files used only one line, I've broken them into several lines just for readability. I would prefer using the /include[:path] option since that seems like a better solution.
Okay, so I think I figured out a workaround at the very least. I understood that the /include[:dir] specifies to search in "dir" for included files. But it seemed from documentation, that this also specifies to search for USEd modules but that doesn't seem to be the case.
My program now looks like this:
include '..\FORTRAN_LIB\__constants.f90'
include '..\FORTRAN_LIB\computeError.f90'
include '..\FORTRAN_LIB\griddata_mod.f90'
include '..\FORTRAN_LIB\myfdgen.f90'
include '..\FORTRAN_LIB\myDiff.f90'
include '..\FORTRAN_LIB\myIO.f90'
program magneticField
use constants
use computeError_mod
use griddata_mod
use myfdgen_mod
use myDiff_mod
use myIO_mod
implicit none
...
And my DF command like this:
df magneticField /exe:magneticField
And everything seems to work fine. It would be nicer to have the /include[:dir] option, but so long I'm able to reach in a separate directory, I'm satisfied. If anyone can find a better solution I'll switch the checkmark. I hope this helps with anyone else who was confused like me.
I have set up team city to compile source code, on every check-in. now i want to do obfuscation using Confuser.how to trigger it automatically after every compile.
It is a bit old now, however I found out the solution and may be useful for someone like me :
Step1 :write a obfuscaticate.crproj file to obfuscaticate your dlls.
sample for 4 dlls:
Step 2:add a build step in team city to execute the bat file(obfuscaticate.crproj) create in step 1.
Make sure you have your crproj file, dlls to obfuscaticate and Confuser dlls like :Confuser.Core.dll etc. in the same folder Dependancy(here in Image)
I am trying to run tests by adding a version of tornado downloaded from github.com in the sys.path.
[tests]
recipe = zc.recipe.testrunner
extra-paths = ${buildout:directory}/parts/tornado/
defaults = ['--auto-color', '--auto-progress', '-v']
But when I run bin/tests I get the following error :
ImportError: No module named tornado
Am I not understanding how to use extra-paths ?
Martin
Have you tried looking into generated bin/tests script if it contains your path? It will tell definitely if your buildout.cfg is correct or not. Maybe problem is elsewhere. Because it seem that your code is ok.
If you happen to regularly include various branches from git/mercurial or elsewhere to buildout, you might be interested in mr.developer. mr.developer can download and add package to develop =. You wont need to set extra-path in every section.