I am trying to install boost on code::blocks on a windows 8 computer. I am using mingw as my compiler because of a library I am using. What exactly does changing/setting a MINGWDIR environment variable do and how does this help me install boost?
Many installations, programs, use this variable to quickly watch exactly where there is a certain environment.
For example:
It is easier to work with your own config batch files.
Also install Boost looking for "MINGWDIR".
Below is a generic example.(Nothing to do with boost).
#echo off
if [%MINGWDIR%] == [] goto environment_not_set
goto start_develop
:environment_not_set
echo
#############################################################################
echo Please adjust environment variables within this file:
set MINGWDIR=c:\mingw
echo
#############################################################################
rem instead of setting MINGWDIR here you could also set them
rem within the registry using the system control
:start_develop
set PATH=%MINGWDIR%\bin;c:\windows;
echo MINGWDIR = %MINGWDIR%
:end
pause
Related
So I am trying to use Libsvm in weka. I've tried what some answers said (I've added the path of the libsvm.jar file to the 'Path' windows variable, and I've check in the SystemInfo tab of Weka and the java.class.path does not contain the libsvm.jar), and I don't understand why since I added it to the path variable.
What can I do to try and fix it? Thanks
You can adapt the CLASSPATH environment variable by creating a little startscript. java.exe takes a -cp argument that sets CLASSPATH that java uses at startup.
So for Windows you could create a script/bat-file weka-start.bat with contents
rem change this to your setting:
WEKA_HOME=%USERPROFILE%/weka-3-9-4
WEKA_JAR=%USERPROFILE%/weka-3-9-4/weka.jar
CP="%WEKA_JAR%;%path_to_libsvm%/libsvm.jar"
rem assuming java.exe is in your %PATH%
java -cp %CP% -Xmx8092m weka.gui.GUIChooser
(untested, off the top of my head. I hope you get the idea.)
I'm a linux user, and my startscript looks like this. It also loads a few database drivers. Works for me…
#!/bin/bash
WEKA_HOME=/opt/smallapps/weka-stable/weka
export WEKA_JAR=$WEKA_HOME/weka.jar
export PATH=$WEKA_HOME:$PATH
CP="/usr/share/java/:/opt/dbvis9/jdbc/jtds/jtds.jar:/opt/database/sqlite/sqlite-jdbc.jar:$WEKA_JAR:/opt/smallapps/weka/wekafiles/packages/LibSVM/lib/libsvm.jar"
echo "used CLASSPATH: $CP"
DIR=/opt/smallapps/weka-stable/data/
echo "changing to '$DIR'"
cd "$DIR"
export WEKA_HOME=$DIR
# start small GUI Chooser
java -cp $CP -Xmx8092m weka.gui.GUIChooser 2>>/opt/smallapps/weka-stable/weka.log &
I followed all the steps successfully as mention in the Qt documentation:
Qt for Linux/X11 - Building from Source
Qt for Linux/X11 -
Deployment
But I still couldn't make static Qt application, the executable generated by the above documented steps still needs Qt shared objects on other system.
Any ideas?
You need to deploy the application, for this purpose I use the utility
cqtdeployer
This utility itself collects all the necessary dependencies of your application and you do not have to spend your time on it, or you can automate this process.
You can install from github releases (Windows)
or
from snapstore (Linux)
sudo snap install cqtdeployer
You can use as follows:
Windows:
%cqtdeployer% -bin myApp -qmake path/to/Qt/5.x.x/build/bin/qmake.exe -qmlDir path/to/my/qml/files/dir
Linux:
cqtdeployer -bin myApp -qmake path/to/Qt/5.x.x/build/bin/qmake -qmlDir path/to/my/qml/files/dir
path/to/Qt/5.x.x/build/bin/qmake - This is the way qmake is used to build your program.
path/to/my/qml/files/dir - this is the path directly to your qml file (which you wrote)
And Run application with sh script (Linux) or exe (Windows)
If you'll use the version from snap then make sure that you have all the permissions.
If you need use windows version just install application from installer
Updated
If you want create a simple installer for you application just add qif option for command of cqtdeployer.
Example :
cqtdeployer -bin myApp -qmake path/to/Qt/5.x.x/build/bin/qmake -qmlDir path/to/my/qml/files/dir qif
Details on all the intricacies of cqtdeployer can be found on the official wiki project.
The best way to deploy your application is not necessarily to statically link it for the following reasons:
LGPL licencing means that your application must now be made public and may not sold (I think) - i.e. since its statically linked and the qt libs are within your executable your executable is now part of the open source.
Its a massive pain in the arse... I have gone around this loop and know the pain well.
Installing qt-everywhere is also not so great, I just don't see how you can garantee that the libraries will be the same version as the ones that your program needs.
So what I started to do was create my own script to deploy qt for me. The basic "jist" of this is that you use ldd to find out which qt libraries you need and copy them into a sub folder (./lib) within the same folder as your executable to make an install bundle.
Note: on Windows there is a deployqt application which does somthing similar (can't remember exactly what it is called).
Below I have copied a version of my deploy script. Note that it is quite old now, but I don't see why it should not work (its not written particularly well), but if not it will give you a start place. Also look out for the plugin's. In this script I have added code to copy the audio plugin since I was using that. If you are using other plugins then you will need to copy those (they are usually in sub dir's of the qt libs like .../audio)... I had a todo to try to figure out what plugins are needed from the .pro file but I never got around to that (I would have to pass in the .pro file to this script as well)...
To run, just run this script and pass in the directory that your executable lives in.
#!/bin/bash
# Rememeber start dir
START_DIR=$PWD
# Determine which dir to deploy in and cd to that dir
if [ -d "$1" ]; then
DEPLOY_DIR=$1
else
DEPLOY_DIR=$PWD
fi
echo "Deploy dir: $DEPLOY_DIR"
cd $DEPLOY_DIR
# Run ldd on all files in the directory and create a list of required qt libs
flag=false
for entry in `ldd $DEPLOY_DIR/* | grep -i qt`; do
if $flag; then
# Only add to the array if it is not already in it
if ! [[ $libsArray =~ $entry ]]; then
echo "adding $entry"
libsArray="$libsArray $entry"
fi
flag=false
fi
# If we see a "=>" then the next line will be a library
if [ $entry == "=>" ]; then
flag=true
fi
done
echo
echo
# Create the required folder structure. Note here we are need the qt audio plugin so we are going to manually copy that as well.
mkdir -p lib
mkdir -p lib/audio
# Now copy these files to the deploy directory
for entry in $libsArray; do
echo "cp -v -f $entry $DEPLOY_DIR/lib"
cp -v -f $entry $DEPLOY_DIR/lib
done
# Now get the audio lib - this is a plugin that we are using so we need these libs as well.
# Add other plugins here as well.
# TODO: maybe we can read this in from the *.pro file.
cp -v -f `qmake -query QT_INSTALL_BINS`/../plugins/audio/* $DEPLOY_DIR/lib/audio
# Go back to start dir
cd $START_DIR
Once you have all the files you need you should be able to copy the whole lot to another PC and run it. Note: you may have to set the export LD_LIBRARY_PATH=<path-to-libs> so that the libs can be found... or install the libs into somewhere like /usr/lib/your-appplication/.
But installing libs is another question/subject!
I have recently installed MinGW to my computer, to compile and run programs written in c.
Right now I have to manually go to the bin-folder to execute and compile files.
The path is C:\MinGW\bin
Is there a a way to avoid this everytime? I want be able to directly write the commands when I open the command Line.
I tried to follow the Environment Settings on http://www.mingw.org/wiki/Getting_Started
but it does not work at all.
A simple solution would be a small batch script. Create a new batch file with this code:
#echo off
cd C:\MinGW\bin
:loop
set /p var=
%var%
goto loop
Could you show me your user environment variable called "path"? Maybe we will find the error there.
Edit:
Create a new environment variable in the upper field (user-environment variables). Enter this in the window which appears.
Name: PATH
Value: C:\MinGW\bin
This should work.
My job mostly consists of engineering analysis, but I find myself distributing code more and more frequently among my colleagues. A big pain is that not every user is proficient in the intricacies of compiling source code, and I cannot distribute executables.
I've been working with C++ using Boost, and the problem is that I cannot request every sysadmin of every network to install the libraries. Instead, I want to distribute a single source file (or as few as possible) so that the user can g++ source.c -o program.
So, the question is: can you pack the Boost libraries with your code, and end up with a single file? I am talking about the Boost libraries which are "headers only" or "templates only".
As an inspiration, please look at the distribution of SQlite or the Lemon Parser Generator; the author amalgamates the stuff into a single source file which is trivial to compile.
Thank you.
Edit:
A related question in SO is for Windows environment. I work in Linux.
There is a utility that comes with boost called bcp, that can scan your source and extract any boost header files that are used from the boost source. I've setup a script that does this extraction into our source tree, so that we can package the source that we need along with our code. It will also copy the boost source files for a couple of boost libraries that we use that are no header only, which are then compiled directly into our applications.
This is done once, and then anybody who uses the code doesn't even need to know that it depends on boost. Here is what we use. It will also build bjam and bcp, if they haven't been build already.
#!/bin/sh
BOOST_SRC=.../boost_1_43_0
DEST_DIR=../src/boost
TOOLSET=
if ( test `uname` = "Darwin") then
TOOLSET="--toolset=darwin"
fi
# make bcp if necessary
if ( ! test -x $BOOST_SRC/dist/bin/bcp ) then
if ( test -x $BOOST_SRC/tools/jam/*/bin.*/bjam ) then
BJAM=$BOOST_SRC/tools/jam/*/bin.*/bjam
else
echo "### Building bjam"
pushd $BOOST_SRC/tools/jam
./build_dist.sh
popd
if ( test -x $BOOST_SRC/tools/jam/*/bin.*/bjam ) then
BJAM=$BOOST_SRC/tools/jam/*/bin.*/bjam
fi
fi
echo "BJAM: $BJAM"
pushd $BOOST_SRC/tools/bcp
echo "### Building bcp"
echo "$BJAM $TOOLSET"
$BJAM $TOOLSET
if [ $? == "0" ]; then
exit 1;
fi
popd
fi
if ( ! test -x $BOOST_SRC/dist/bin/bcp) then
echo "### Couldn't find bpc"
exit 1;
fi
mkdir -p $DEST_DIR
echo "### Copying boost source"
MAKEFILEAM=$DEST_DIR/libs/Makefile.am
rm $MAKEFILEAM
# Signals
# copy source libraries
mkdir -p $DEST_DIR/libs/signals/src
cp $BOOST_SRC/libs/signals/src/* $DEST_DIR/libs/signals/src/.
echo -n "boost_sources += " >> $MAKEFILEAM
for f in `ls $DEST_DIR/libs/signals/src | fgrep .cpp`; do
echo -n "boost/libs/signals/src/$f " >> $MAKEFILEAM
done
echo >> $MAKEFILEAM
echo "### Extracting boost includes"
$BOOST_SRC/dist/bin/bcp --scan --boost=$BOOST_SRC ../src/*/*.[Ch] ../src/boost/libs/*/src/*.cpp ../src/smart_assert/smart_assert/priv/fwd/*.hpp $DEST_DIR
if [ $? != "0" ]; then
echo "### bcp failed"
rm -rf $DEST_DIR
exit 1;
fi
Have you considered just writing a build script for a build system like SCons?
You could write a python script to download boost, unpack it compile the needed files (you can even run bjam if needed) and compile your own code.
The only dependency your colleagues will need is Python and SCons.
Run the preprocessor on your code and save the output. If you started with one main.cpp with a bunch of includes in it, you will end up with one file where all of the includes have been sucked in. If you have multiple cpp files, you will have to concatinate them together and then run the preprocessor on the concatinated file, this should work as long as you don't have any duplicate global symbol names.
For a more portable method, do what sqlite does and write your own script to just combine and concatinate together the files you created+boost, and not get the system includes. See mksqlite3c.tcl in the sqlite code
http://www2.sqlite.org/src/finfo?name=tool/mksqlite3c.tcl
Why not just check in all the necessary files to SVN, and send you co-workers the URL of the repository? Then they can check out the code whenever they want to, do an 'svn up' any time they want to update to the latest version, etc.
If you're on a Debian-derived variety of Linux, well problems like this just shouldn't come up: let the packaging system and policy manual do the work. Just make it clear that the libboost-dev or whatever package is a build-dependency of your code and needs to be installed beforehand, and then /usr/include/boost should be right there where your code expects to find it. If you're using a more recent version of boost than the distro ships, it's probably worth figuring out how to package it yourself and work within the existing packaging/dependencies framework rather than reinventing another one.
I'm not familiar enough with .rpm based distros to comment on how things work there. But knowing I can easily setup exactly the build environment I need is, for me, one of the biggest advantages of Debian based development over Windows.
When I try run make from cmd-console on Windows, it runs Turbo Delphi's make.exe but I need MSYS's make.exe. There is no mention about Turbo Delphi in %path% variable, maybe I can change it to MSYS in registry?
The path is in the registry but usually you edit through this interface:
Go to Control Panel -> System -> System settings -> Environment Variables.
Scroll down in system variables until you find PATH.
Click edit and change accordingly.
BE SURE to include a semicolon at the end of the previous as that is the delimiter, i.e. c:\path;c:\path2
Launch a new console for the settings to take effect.
Here I'm providing solution to setup Terraform environment variable in windows for beginners.
Download the terraform ZIP file from Terraform site.
Extract the .exe from the ZIP file to a folder eg C:\Apps\Terraform
copy this path location like C:\Apps\terraform\
Add the folder location to your PATH variable, eg: Control Panel -> System -> System settings -> Environment Variables
In System Variables, select Path > edit > new > Enter the location of the Terraform .exe, eg C:\Apps\Terraform then click OK
Open a new CMD/PowerShell and the Terraform command should work
Or you can just run this PowerShell command to append extra folder to the existing path:
$env:Path += ";C:\temp\terraform"
To add a PERSISTENT path (eg one that's permanent), you can do this one-liner in PowerShell (adjust the last c:\apps\terraform part)
Set-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment' -Name PATH -Value (((Get-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment' -Name PATH).path) + ";c:\apps\terraform" )
Alternatively, you can jump directly to the Environment Variables dialog by RUNning/CMD/PowerShell this:
rundll32.exe sysdm.cpl,EditEnvironmentVariables
I had issues for a whilst not getting Terraform commands to run unless I was in the directory of the exe, even though I set the path correctly.
For anyone else finding this issue, I fixed it by moving the environment variable higher than others!
Why don't you create a bat file makedos.bat containing the following line?
c:\DOS\make.exe %1 %2 %5
and put it in C:\DOS (or C:\Windowsè or make sure that it is in your %path%)
You can run from cmd, SET and it displays all environment variables, including PATH.
In registry you can find environment variables under:
HKEY_CURRENT_USER\Environment
HKEY_CURRENT_USER\Volatile Environment
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment
just copy it to system32 call make1 or whatever if the name conflicts.