This question already has answers here:
Prevent SCons from looking for standard tools
(3 answers)
Closed 7 years ago.
I am using SCons in our python project to automate some steps. We do not use C/C++ in this project, and we do not have Visual C++, or any other C++ compilers installed in our build machine. However, SCons always gives a warning:
scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly
File "D:\BuildAgent\work\dea9985b7c13c306\CCARModeling\SConstruct", line 14, in
We pinned it down to the line:
env = Environment(BUILDERS = {'RModels' : RBuilder}, ENV = os.environ)
There is no reason Scons should always look for a C++ compiler. Is there a way to suppress this particular warning?
You can use
env = Environment(tools=[])
to disable loading any default tools, and you may want to do the same for the DefaultEnvironment. Depending on which Builders/Tools you actually need, you can give the list instead, like this:
env = Environment(tools=['ar', 'textfile'])
See also the UserGuide at http://www.scons.org/doc/production/HTML/scons-user.html , especially 7.2.5 Controlling the Default Environment.
Related
I have built llvm-13.0.1 from source using Visual Studio 17 2022 on Windows 11. When attempting to build llvm-sys (through external crate llvm-ir). It fails, saying:
error: No suitable version of LLVM was found system-wide or pointed to by LLVM_SYS_130_PREFIX.
I know llvm-config exists because I can use it from the command line, and it returns the correct version. I don't understand why this doesn't work. This might be a stupid question but I am really stuck.
I was also having this problem, trying to use llvm-sys on Windows. Here are some mistakes that I did that made it fail to compile just like yours.
Installation Prefix
Make sure that your LLVM installation path doesn't have any whitespace.
Mine was -DCMAKE_INSTALL_PREFIX=C:\Program Files (x86)\LLVM, which was their default install prefix. The whitespace in the installation path causes some errors when using it with llvm-sys. Later, I changed it to C:\LLVM and it worked.
Set Environment Variable
Set Environment Variable LLVM_SYS_<version>_PREFIX to the installed LLVM folder.
From CMD For LLVM-13.0.1
setx LLVM_SYS_130_PREFIX "<PATH TO LLVM WITHOUT WHITESPACE>" /M
Make sure that the variable is registered by using echo command
echo %LLVM_SYS_130_PREFIX%
It should output your registered path, not %LLVM_SYS_130_PREFIX%.
If it doesn’t output your path, restart the computer and try again and it should be working.
Now you should be good to go .....
Hope this helps :)
I wrote a python script which runs some Modelica scripts file for Gitlab pipeline continuous integration. I could get the python script to work from command line without any issues, however, whenever I trigger the pipeline in Gitlab, I got errors below, I am curious if anyone encountered similar issues and could provide a solution possibly?
No compiler selected. Please select a version of Visual C++ or GCC. For instructions on how to install a supported compiler, please visit www.dymola.com/compiler.
I tried to use SetDymolaCompiler method, but it still gives me the same error.
(BTW, the documentation in the python interface was incorrect. In the documentation, string lists (see marco's answer and my correction) were used to set compiler location, however, I figured that it should be a map actually).
Here's the code I was running:
dymola_obj = None
try:
dym_obj = DymolaInterface(dymola_exe)
dym_obj.cd(mc_work_dir)
dym_obj.SetDymolaCompiler("vs", {"CCompiler":"MSVC","MSVCDir":"C:/Program Files (x86)/Microsoft Visual Studio 11.0/Vc"})
success = dym_obj.ExecuteCommand("some command")
except DymolaException as ex:
success = False
finally:
if dym_obj is not None:
dym_obj.close()
dym_obj = None
return success
OS: Win 10 Pro (on a VM)
Dymola: 2018 FD01
Correction:
Python interface documentation is still incorrect, in order to change compiler settings one should use [] instead of { }.
Python interface documentation:
SetDymolaCompiler("vs", {"CCompiler=MSVC","MSVCDir=C:/Program Files (x86)/Microsoft Visual Studio 10.0/Vc"});
Should be changed to:
SetDymolaCompiler("vs", ["CCompiler=MSVC","MSVCDir=C:/Program Files (x86)/Microsoft Visual Studio 10.0/Vc"]);
I didn't try with gitlab, but I found an error when running your code on my machine with Dymola 2018 FD01 and python 2.7.
In fact SetDymolaCompiler really does require a list of strings. You have to replace the line
dym_obj.SetDymolaCompiler("vs", {"CCompiler":"MSVC","MSVCDir":"C:/Program Files (x86)/Microsoft Visual Studio 11.0/Vc"});
with
dym_obj.SetDymolaCompiler('vs', ['CCompiler=MSVC', 'MSVCDir="C:/Program Files (x86)/Microsoft Visual Studio 11.0/Vc'])
Some tips when working with the python interface:
activate the Dymola window during development with
DymolaInterface(showwindow=True)
set breakpoints and check after every command what Dymola writes to the command window. In your case it got obvious that SetDymolaCompiler was not executed due to syntax errors and the compiler was not set
And finally, your minimal example does not work, as python code lines must not end with ;
The VS environment variable is set beforehand with vcvars32.bat, and VS is the only compiler that I use; the OS is win 7.
The error happens with cmake-gui; specifying the compiler with path results in error 'compiler failed to make simple test'; alternatively, cmake -i from command line succeeds initially with presenting an 'options' menu which then fails to allocate a 'cmakelists.txt' file (which is somewhere deeper in the cmake folder).
Where am I going wrong?
(I continued with building the solution files from VS 12, but there's other issues.)
The answer to your question from cmake mailing list
Run cmake-gui FROM the target environment, just like you run cmake...
i.e. : type "cmake-gui" in the cmd prompt that has your stuff set up
in it. Don't just launch it from a short-cut unless you're using the
"Visual Studio *" generators. Those do not need any special
environment. Many of the makefile ones do.
Is there a version of the package RDCOMEvents that works in recent versions of R (2.14 or 2.15)?
I've been trying to get the example on the penultimate page of http://www.stat.berkeley.edu/~nolan/stat133/Fall05/lectures/DCOM.pdf to work - the one starting with the lines
library(RDCOMClient)
library(RDCOMEvents)
I can install RDCOMClient without a hitch, but not RDCOMEvents as it says that the package was built before R 2.10.0.
Any tips that can get me up and running very gratefully received... thanks :)
EDIT (16 July 2012):
Tried installing from the source as suggested, but no good (see below). Really disappointing that such an invaluable package seems to have been left to rot!
C:\mypackage>R CMD INSTALL RDCOMEvents_0.3-1.tar.gz
* installing to library 'C:/Users/timp/Documents/R/win-library/2.13'
* installing *source* package 'RDCOMEvents' ...
** libs
running src/Makefile.win ...
c:/MinGW/bin/g++ -g -Id:/duncan/Projects/R/R-check/src/include -D_GNU_ -DNO_PYCO
M_IPROVIDECLASSINFO -DUSE_R -Wno-deprecated -I. -c -o events.o events.cpp
events.cpp:12:18: fatal error: Defn.h: No such file or directory
compilation terminated.
make: *** [events.o] Error 1
ERROR: compilation failed for package 'RDCOMEvents'
* removing 'C:/Users/timp/Documents/R/win-library/2.13/RDCOMEvents'
EDIT 2 (16 July 2012):
RExcel has been suggested as an alternative approach - can anyone point me to an RExcel example where buttons/handlers in the sheet are generated from within R (as in the example quoted above), rather than the spreadsheet designer having to grapple with VBA code within the spreadsheet? Given that this R-centric approach was possible a few years ago, it must surely still be possible now... somehow...
Well, you could try installing the packages from source code which is available for both packages here and here.
Once you've unpacked the archives you can build and install them using R from the command-line, e.g.
R CMD install RDCOMClient
or
R CMD install RDCOMEvents
Unfortunately the build fails on my system (OS X here) as the necessary Microsoft C compiler and libraries aren't available. I guess you'll have to install Visual Studio along with the rest before you can build and install these packages.
Hope it helps anyway!
The last update to RDCOMEvents is 2005. It hasn't been automatically compiled for newer versions of R because it would require the Visual Studio compiler, and is really only useful for the Windows operating system. (I tried compiling it with the ming compiler too, but there are directives in there that are dependent on Visual Studio.)
So, you could grab Visual Studio, and try to get it to compile. I don't envy that task.
However, you may not be aware of the RExcel package. They have also developed a package to get R to talk to Excel (and Word) through the DCOM stuff. It is free for single non-commercial use. I don't think the middleware is open source, but it works. Not an answer to your question, but perhaps good enough?
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
How can I configure Vim to compile C code using Borland’s compiler on Windows?
I have been trying to compile a simply c code using Gvim 7.2.
I have the Borland bcc32 compiler installed, but I keep getting the message
"make is not recognized as an internal or external command".
What am I doing wrong? What should I include in my _virmrc file to
correct the problem or what configuration do I need to set to compile my code?
Take a look at Introduction to Programming in C/C++ with Vim.
In this situation VIM is looking for your make.exe. Either put this on the path, or set the variable makeprg e.g.
:set makeprg={path to your make exe}
Have you added the directory with Borland's make.exe to your %PATH%?
Right click on My Computer → Properties → Advanced → Environment Variables
That error suggests that Vim cannot find make.
Troubleshooting steps:
Is make installed?
Is the directory containing the make executable in your path?
Can you run make from the command line?
Can you run make from inside of vim?
Information that would help:
Which version of Windows are you using?
Is the path to make in your system path? I would check there first.