Using kitware's CMake, is it possible to automatically download a Microsoft installer (MSI) file and execute it (on Windows, of course)?
It generally should be. However, clearly running the installer will block the CMake process until the user completes all the required inputs to the installer.
Here's an example for 7-zip's installer making use of file(DOWNLOAD ...) and execute_process:
set(DownloadedMsi ${CMAKE_BINARY_DIR}/7z920-x64.msi)
file(DOWNLOAD http://sourceforge.net/projects/sevenzip/files/7-Zip/9.20/7z920-x64.msi/download
${DownloadedMsi}
TIMEOUT 30
STATUS StatusVar
LOG LogVar
EXPECTED_HASH SHA1=4173fea2af9a595fa0be1ef8251f412229687be1)
message("\${StatusVar} - ${StatusVar}")
message("\${LogVar} - ${LogVar}\n\n\n")
execute_process(COMMAND cmd /c "${DownloadedMsi}"
RESULT_VARIABLE ResultVar
OUTPUT_VARIABLE OutputVar
ERROR_VARIABLE ErrorVar)
message("\${ResultVar} - ${ResultVar}")
message("\${OutputVar} - ${OutputVar}")
message("\${ErrorVar} - ${ErrorVar}")
Related
I'm downloading an executable via curl and try to run it afterwards. However, the Command object responsible for running it crashes with the following message: %1 is not a valid Win32 application. (os error 193)
Here's a snippet for better context:
let link = "https://download.bell-sw.com/java/18.0.1.1+2/bellsoft-jre18.0.1.1+2-windows-amd64-full.msi";
Command::new("curl")
.args(["-O", link])
.output()
.unwrap_or_else(|err| panic!("{err}"));
let program = format!("./{}", link.split('/').last().unwrap());
Command::new(program)
.output()
.unwrap_or_else(|err| panic!("{err}"));
A .msi file is not an executable. To install it you need to run msiexec.exe /i "c:\path\to\installer.msi" /qn.
To open the file like Explorer you would have to call the ShellExecute WinApi...
I have successfully built OpenDDS 3.13.2 from source. Here is my environment:
Windows 10
Visual Studio 2017 (re-targeted Solution to SDK 10.0.17763.0)
Tried all Configuration/Platform combinations
I successfully used the configure script from the VS command prompt, built everything by opening the generated solution in the same command prompt, and finally ran the Messenger example (publisher and subscriber), and even configured it to use RTPS successfully.
However, when I try to create my own IDL and use the tao_idl, it crashes. Here's my test (using the proper environment from setenv.cmd):
> tao_idl (no args)
IDL: No input files
Second test:
> tao_idl Test.idl (crashes)
I get no error message, and am unable to locate logs or any indication of what went wrong. The same thing happens when I used opendds_idl.
What is the best approach to debug this, and/or are there pre-built binaries available for the IDL compiler(s) (both TAO and OpenDDS)?
After about a day of troubleshooting, I have determined a solution. Despite being able to call tao_idl and opendds_idl yourself, you should basically never do it. There are a good amount of command-line arguments needed to get both to work, and if they're not present, each exe will crash without the proper reasoning why.
I will add my steps below to create a new basic two-exe pub/sub project using OpenDDS:
Create your own IDL file.
Starting with the DCPS Messenger example, modify the .mpc file, replacing Messenger.idl with your IDL file name.
Create a new file called <your project>.mwc, and add the following contents:
workspace {
// the -relative and -include cmdlines make it so this workspace
// does not have to be in the $DDS_ROOT directory tree.
// tell MPC to substitute our DDS_ROOT environment variables for relative paths
cmdline += -relative DDS_ROOT=$DDS_ROOT
// tell the projects where to find the DDS base projects (*.mpb)
cmdline += -include $DDS_ROOT/MPC/config
}
Open a new VS command-line terminal and run $DDS_ROOT/setenv.cmd, or open a regular terminal if you have those environment variables set via Windows settings.
Navigate to your project directory and call: mwc.pl -type vs2017, replacing "vs2017" as needed for your build tool/IDE.
Open up the generated solution, and retarget it as necessary for your Windows SDK version.
Build the <your project>_IDL project first. If you notice in the output window, it is invoking the tao_idl and opendds_idl commands automatically. You can view the .vcxproj files to see the full command-line arguments that were the original problem.
Modify the publisher.cpp, subscriber.cpp, and DataReaderListenerImpl.cpp files to match your new IDL. Run the example as usual and ta-da!
For completeness, the full commands for both tao_idl and opendds_idl are as follows:
> opendds_idl -Sa -St "<your file>.idl"
> tao_idl -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -Sa -St -I$(DDS_ROOT) "<your file>.idl"
> tao_idl -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -Sa -St -I$(DDS_ROOT) "<your file>TypeSupport.idl"
I'm having trouble with a Jenkins pipeline.
The thing is, it seems one of the steps is running in parallel with another (not intentionally):
I have something like:
...
step("build"){
bat [Visual Basic 6 compile command - vb6.exe file.vbp /outdir my/directory]
if(fileExists("my/directory/output.dll"){
println "SUCCESS"
}else{
error("error")
}
...
}
Ok, the problem is: it checks if the files exist before it's written by the compile command... If I put a sleep 10 before the condition, it always runs OK (for now), but obviously, I don't want to have a sleep command in my pipeline.
I don't know if I can control better the order os execution or if maybe the fault lies in the vb6.exe that creates a thread to write the output and then the main thread returns success before the output being written... does this make sense? Does anyone know how may I solve this problem?
My solution is to make the VB6 compilation step blocking.
This is what I run when working locally on my machine:
cmd /c VB6.exe /make someproject.vbp
And it is also the approach used by the Jenkins Visual Basic 6 plugin (I am the author). See this.
I am doing some work on cordova-windows (https://github.com/apache/cordova-windows), which is using AppVeyor for testing on Windows. One of the things that was missing, were tests with Visual Studio 2017 (only VS2015 was used to test before). So I added those and it works like a charm - mostly.
Unfortunately we now have a very strange test failure:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/cordova-windows/build/1.0.458
Started
Creating Cordova Windows Project:
Path: testcreate 応用
Namespace: com.test.app
Name: 応用
Windows project created with cordova-windows#5.1.0-dev
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x64
Patching 10 in prebuild event...
Injected base.js reference to the www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.WinJS.2.0\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.Phone.WinJS.2.1\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\Upload\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_Test\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_x64_bundle.appxupload
Your package has been successfully created.
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x86
Patching 10 in prebuild event...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\q\q.js:155
throw e;
^
Error: C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe: Command failed with exit code 1
at ChildProcess.whenDone (C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\cordova-common\src\superspawn.js:169:23)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at maybeClose (internal/child_process.js:920:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:230:5)
The relevant part is this:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
This is not happening when I run the tests locally, meaning I can in no way reproduce what is going on here.
Any idea what process could block this Default.rd.xml file or build\windows\bld\PackageUploadLayout\?
How can I find out in a CI environment like AppVeyor?
Update:
Investigated a bit more by adding /clp:Verbosity=normal to the msbuild calls that are executed.
It runs a similar msbuild call 3 times (once per architecture). The first one succeeds, but during the second one the failure occurs. Makes sense as in the first iteration the folder doesn't exist yet, which it confirms with this output: Directory "build\windows\bld\PackageUploadLayout\" doesn't exist. Skipping..
The last output before the failure then is Removing directory "build\windows\bld\PackageUploadLayout\". which matches what we get in the error message. No indicator why the removing doesn't work though.
Super strange: With /clp:Verbosity=detailed added to the msbuild call, the build actually succeeds! My guess: Because the output takes time, whatever is having a lock on the folder or file releases it.
This is not exactly an answer, but rather investigation report. It is just not enough room comments to describe it. Here is what I did:
forked your repo
created AppVeyor project
added RDP
connected with RDP
installed procmon
added filter to monitor objects which path ends with bld\PackageUploadLayout\Properties\Default.rd.xml
run npm test manually from CMD
When the same error happened I see this:
I am not sure I understand why msbuild failed this way. I opened SHARING VIOLATION event, switched to process and see this:
What catches my eye is that msbuild version is 14. Should be 15 on Visual Studio 2017 image. We have version 14 installed for specific scenarios but default one is 15 (run where msbuild and you will see C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe). I am not sure where this path is set in your scripts, but I feel if you make it run correct msbuild version this may help.
I have a Makefile-powered project in Visual Studio 2010 (uses NAnt, in fact, but that's beside the point).
The output of the build process is a .elf file, and I have a separate, non-VStudio debugger which can be run on that .elf file to debug it.
Building works fine, but when I click the 'debug' button (little green triangle), VStudio fails with "Unable to start program 'XXX.elf'. The specified file is an unrecognized or unsupported binary format"
I'm guessing VStudio is just trying to 'run' the .elf as though it were an .exe, and failing.
What I really want VStudio to do is run "my_debugger.exe XXX.elf" when I press the debug button.
I have tried adding a file association with .elf=>my_debugger.exe
I have updated PATHEXT appropriately as well, and run VStudio under those changes.
Still no luck.
Isn't there somewhere in VStudio where you can specify a custom debug command? I thought there was, but can't find it.
I could just have the build process output a .bat file or something I guess, but this seems silly.
As Jim mentioned you can specify which app to start on run in the project settings (Command field). If you place a debugger there you can pass down your executable as an argument to the debugger being launched (Command Arguments field). This way you can launch the debugger which in turn will launch your executable if the debugger expects any commandline arguments.
MinGW on Windows example:
Command: gdb.exe; Command Arguments: Path\ToMyApp\whatever.exe
will start gdb.exe, gdb.exe will open whatever.exe, parse the debug info and wait for debug instructions.
Command: msys.exe; Command Arguments: gdb.exe Path\ToMyApp\whatever.exe
will start msys.exe, msys.exe will execute "gdb.exe Path\ToMyApp\whatever.exe"
Look at the project properties. Do you have a Debug tab which has a Start Action section giving three choices? Those choices would be: ( ) Start project, (x) Start external program: ... ( ) Start browser with URL.
You can also set the command line arguments and working directory.
Cf. How to: Change the Start Action for Application Debugging