I'm porting my game engine to linux and don't know how to locate my data without copying it. Before the data was in myproject/bin together with the produced exectuable.
With cmake default structure, the binaries go under myproject/build/source/launcher/release/launcher.exe separated from the data. I can locate it with visual studio, setting the working directory to the same path(myproject/data). But I would like a general solution directly from cmake. Mosts answers I've read copy the data to each build or generate a path variable pointing to the data. There's to much data to have duplicates for debug/release and it just doesn't feel right to copy it.
What is the best option here? What is most common in game development?
You could try https://github.com/caseymcc/CreateLaunchers, with Visual Studio/Windows it will create a .user file(vs debug info) and a batch file that you can set the command, command line args, path to dlls, working directory and any other environment variables you need.
On linux it will produce a shell script with the same info.
Related
I have a project in IntelliJ IDEA, inside that a couple of modules and one of my modules has two build configurations. One of them needs to copy a <projectroot>/tools folder to its out/production/<BuildConfigurationName> folder. Can IDEA somehow automate this?
The accepted answer above is incorrect. IDEA can do this (without ant/gradle) via the artifacts system (accessed via Build menu or project settings). Any one artifact job copies multiple files/folders/build outputs to a chosen location (optionally jarred) and can be set to automatically run on make.
Artifacts can even be chained, i.e. output from one as input to another.
Can IDEA somehow automate this?
Not directly, no. Ultimately IDEA is an IDE and not a build tool. While it can do a lot during a build, it does not have the ability to copy non-source files to an alternate directory, let alone a dynamically named directory.
If you marked the tools directory as a source directory (and none of its contained file types were set in the "Ignore files and folder" setting at the bottom of the "File Types" settings dialog), IDEA would then copy the tools directory to the out directory. But renaming requires a more sophisticated build tool.
Ultimately, the "ideal" or "best practices" solution would be to build your project using a build tool like Maven, Gradle or Ant for which this type of thing would be a snap.
If that is not an option, or for some reason you really want IDEA to do the build, the best thing you could do is to write a simple Ant script to the copy for you. (Or possibly Gradle, I do not have much experience with Gradle yet. Maven could do it, but it'd be a bit cumbersome compared to Ant.) In any Run/Debug configurations, you can define the ant script target to run before or after the IDEA "make" in the Before Launch section. (You can set that as a default for any newly created configurations by configuring it in Defaults on the left). If you run your build manually, you can assign a shortcut to the ant build and then run it and the make in sequence. Alternatively, you could record a Macro (Edit > Macros) to run both in sequence and then (optionally) assign the macro a keyboard shortcut.
I'm currently automating my the installation process for multiple instances of an application. This application uses cmake for building and uses some libraries for which no findModule.cmake files exist. Since I'm could find a good example how to generate a findModule.cmake file for existing libraries for example OpenCascade. When setting up the buildprocess manually one can easily adapt the include and lib path in ccmake. Since I want to automate this I'm looking for a way to do this by passing the options to cmake on the command line. Here is how I try to achieve this for OpenCascade:
cmake -DOCC_FOUND:INTERNAL=TRUE -DOCC_INCLUDE_DIR:PATH=/usr/include/opencascade -DOCC_LIBRARY:FILEPATH=/usr/lib/libTKernel.so -DCMAKE_BUILD_TYPE:STRING=Release ..
Unfortunately this doesn't work. Since the option for building are build-depended, passing a previously configured CMakeCache.txt file is not working.
Thanks for any suggestions to achieve what I'm trying to do.
I am using MSbuild to create a deployment package (simply copying various files from the projects in my solution to different folders) I would like the root folder to be of the format
DeploymentPackage2.3.4.5ForRelease
How can I get MSbuild to put the Assembly number in the folder name automatically?
EDIT:
The solution has a great deal of projects in it (too many really) they all get their version number from a SharedAssemblyInfo.cs file that is manually updated but in the fullness of time will pick up the svn build number (but that is a job for later)
I am building using an external .bat file that calls a custom written .targets/.proj setup that simply calls msbuild on the .sln of the solution.
The 'create package' step I am trying to create happens after a succesful build and will eventually be run by our CI framework, however I would like to be able to run it locally too.
I have created a "CreatePackage" target that does the copying that I want, however it is currently into a fixed folder. I need the folder name to reflect the AssemblyVersion of one of the final dll's.
If there is a better way then I want to know about it... but I am going to use this I think
MSBuild Task to read version of dll
I am trying to update an application that was developed a couple of months ago on VB of Visual Studio 2005.
The "Build output path:" for the project is pointing to a folder in which I collected a few executables related to my activity, BinDir/. It is just next to the project's folder ProjName/ on my disk.
Contrary to the past, when I build my project now, the .exe is created in the ProjName/obj/Debug folder, instead of being directed to the BinDir/Debug folder.
In the IDE's Output tab (while building), the path of the generated executable appears correctly, but in reality it is located somewhere else.
Why is it so?
UPDATE: Something very peculiar is going on my computer today... A couple of hours later I tried again and now it seems like the executable is created in both places. The obj/ version is just redundant now.
What you describe seeing in the Update is what usually happens with Visual Basic builds in Visual Studio 2005. The build creates the executable in an intermediate directory (obj\debug) and then copies the executable from there to the final build output directory (bindir\debug)
With the usual minimal logging turned on, if you examine the build output, you should see the vbc command include the switch /out:obj\Debug\yourproject.exe which tells the compiler to create the executable in the obj\debug fdirectory. Then you should see the file get moved to the build output yourproject -> C:\TestPrograms\Vb.net\yourproject\bin\Debug\yourproject.exe
If you use Tools | Options | Projects and Solutions | Build and Run to set the "MSBuild project build output verbosity" property to "Detailed" you can see a lot more activity against the obj\debug directory and then see the various project output files being copied from that intermediate directory to the build output directory.
The macros $(Targetdir) and $(IntermediateOutputPath) can be used to access these two directories as can be seen using a build event like this...
echo target: $(Targetdir)
echo intermediate: $(IntermediateOutputPath)
In the original question, it sounds like the copy from intermediate to build output either failed or was not attempted leaving you with only one copy of the exe in the intermediate directory.
It's too late to go back and look now but typically the build output window will tell you more about why the copy failed.
I know that the latest book out on MSBuild says this is not possible, but I am sure I have seen a property that points to the current file.
Does anyone know a way to find the current file? (ie When the main MSBuild file imports a secondary file. What is the path to the secondary file from inside that file.)
I am trying to register my file in HKEY_LOCALMACHINE\Software\Microsoft\VisualStudio\8.0\MSBuild\SafeImports, but the path to the file is not constant on each of my coworkers computers and it is imported from several different projects so doing a hard coded relative path is not a good idea either.
If there is a way to get the current working directory that will work too (the working directory switches with each import and I think I could save it off)
There is not a reliable means to identify the "current file". When MSBuild processes a file it can import several other files, the end result is a single in memory complete representation of the file. When the targets are executing they do not know which file they were declared in.
This is why reusable build scripts must be "parameterized" to accept the location to known relative locations. For example if you have a dependency on the location where your folder for 3rd party references are located, the build script which is driving the process must declare that property for you.
MSBuild 4.0 Only
If you are using MSBuild 4.0, i.e. Visual Studio 2010/.NET 4.0, (which can target .NET 2.0/3.0/3.5) as well. Then you now have these properties which can be used for this specific purpose:
MSBuildThisFile
MSBuildThisFileDirectory
MSBuildThisFileDirectoryNoRoot
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
In 4.0+ you can use properties like $(MSBuildThisFile) to do exactly this. See here