Assume a Visual C++ solution that outputs several executables. These executables are meant to be run in a certain order and with certain parameters -- and for this purpose there already is an ant build.xml script.
What would be a decent approach to integrating this ant script with VC++, such that the ant script will point against the recently output executables (.\Debug and .\Release folders) and ideally could be run directly from VC++, and dare I say with remote debugging.
I was thinking of using build post-events that populate a build.properties file with the output location of each executable, and let the ant script use this .properties file.
Any help on the matter would be great.
I'm not sure if there is a good answer for this. Perhaps you are not asking the right questions. From C++ you can launch anything, including scripts. I'm not sure what you mean by VC++ integration.
The generic answer would be:
save the output locations somewhere, doesn't matter where (file, registry, environment variables etc.)
retrieve them in the script before use
But depending on what you need, you could also try:
Output the same executables in the same folder structure. This way you can use relative paths.
Use a post-build event which copies the script in the output folder and make it use the relative path.
Instead of a script you can also try handling everything from the first EXE. Instead of an ANT script it could use a configuration file which specifies execution order and parameters.
Related
I need to make my Autohotkey scripts run at startup, so I think the best way is to save the file .exe in the startup folder, but the .exe file is saved automatically in the same folder of the source, so save the source in the startup folder could be a solution too, but it also opens the source at startup.
Now I'm using the syntax highlight plugin for autohotkey in SublimeText3, but I don't know if there are some way to save the .exe file to a different folder than the one where the source (I'm a noob in informatic).
I'd tried using SetWorkingDir in the Autohotkey script and costumizing the AutoHotkey.sublime-build file using working_dir, but I don't know how they work, so I didn't achieve the goal.
I need a way to edit .ahk with Sublimetext3, keeping my scripts in "documents" and, when I build, save the exe in another folder.
If you're just looking to have your AHK files load when you start up Windows, then the Startup folder is indeed the right location. An elegant solution would be to call the other scripts from this main script.
Since the default AutoHotkey.ahk script is contained in your Documents folder, you can include or run various other AHK scripts, depending on whether you want them to run under one AutoHotkey instance, as one per script, or some combination of the two.
Documentation on Include is fairly solid. The example from the linked page:
#Include C:\My Documents\Scripts\Utility Subroutines.ahk
#Include %A_ScriptDir% ; Changes the working directory for subsequent #Includes and FileInstalls.
#Include C:\My Scripts ; Same as above but for an explicitly named directory.
Similarly, you can Run like below:
Run, C:\My Documents\Scripts\Utility Subroutines.ahk
I am not sure I understood well your question. (Maybe you could make it clearer)
To run an .ahk at startup you can save it in your startup folder and you need simply to associate .ahk with the AutoHotkey.exe. (Always open with AutoHotkey.exe). You don't have to have the 2 files in the same location.
You could also add a shortcut to your .ahk file to your startup folder.
If you have many scripts copy each shortcuts to the startup folder.
I've defined a CMakeLists.txt file for my project which works correctly.
I use the CMake GUI for generating a Visual Studio Project, and I ask to build the binaries (CMAke cache and other stuff) in the folder Build which is in the same folder where CMakeLists.txt is.
I was able to specify where the executable and the libraries have to be created.
Is there a way to specify also where the Visual Studio Solution file has to be created? I would like to have it in the root directory, but at the same time I don't want to have also all the other files that CMake creates in the Build directory.
CMake creates the Project I defined in CMakeLists.txt but also two other projects: ALL_BUILD and ZERO_CHECK. What's their utility?
I was able to avoid the creation of ZERO_CHECK by using the command set_property(GLOBAL PROPERTY USE_FOLDERS On).
Is there a way for avoiding also the creation of ALL_BUILD?
It seems you only switched to CMake very recently, as exactly those questions also popped into my head when I first started using CMake. Let's address them in the order you posted them:
I use the CMake GUI for generating a Visual Studio Project, and I ask
to build the binaries (CMAke cache and other stuff) in the folder
Build which is in the same folder where CMakeLists.txt is.
Don't. Always do an out-of-source build with CMake. I know, it feels weird when you do it the first time, but trust me: Once you get used to it, you'll never want to go back.
Besides the fact that using source control becomes so much more convenient when code and build files are properly separated, this also allows to build separate distinct build configurations from the same source tree at the same time.
Is there a way to specify also where the Visual Studio Solution file has to be created?
You really shouldn't care.
I see why you do feel that you need full control over how the solution and project files get created, but you really don't. Simply specify the target for the solution as the origin of your out-of-source build and forget about all the other files that are generated. You don't need to worry, and you don't want to worry - this is exactly the kind of stuff that CMake is supposed to take care of for you.
Ask yourself: What would you gain if you could handpick the location of every project file? Nothing, because chances are, you will never touch them anyways. CMake is your sole master now...
CMake creates the Project I defined in CMakeLists.txt but also two
other projects: ALL_BUILD and ZERO_CHECK. What's their utility? I was
able to avoid the creation of ZERO_CHECK by using the command
set_property(GLOBAL PROPERTY USE_FOLDERS On). Is there a way for
avoiding also the creation of ALL_BUILD?
Again, you really shouldn't care. CMake defines a couple of dummy projects which are very useful for certain internal voodoo that you don't want to worry about. They look weird at first, but you'll get used to their sight faster than you think. Just don't try to throw them out, as it won't work properly.
If their sight really annoys you that much, consider moving them to a folder inside the solution so that you don't have to look at them all the time.
Bottom line: CMake feels different than a handcrafted VS solution in a couple of ways. This takes some getting used to, but is ultimately a much less painful experience than one might fear.
You don't always have a choice about what your environment requires. Visual Studio's GitHub integration requires that the solution file exists in source control and is at the root of the source tree. It's a documented limitation.
The best I was able to come up with is adding this bit to CMakeList.txt:
# The solution file isn't generated until after this script finishes,
# which means that:
# - it might not exist (if this is the first run)
# - you need to run cmake twice to ensure any new solution was copied
set(sln_binpath ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.sln)
if(EXISTS ${sln_binpath})
# Load solution file from bin-dir and change the relative references to
# project files so that the in memory copy is as if it had been built in
# the source dir.
file(RELATIVE_PATH prefix
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR})
file(READ ${sln_binpath} sln_content)
string(REGEX REPLACE
"\"([^\"]+).vcxproj\""
"\"${prefix}/\\1.vcxproj\""
sln_content
"${sln_content}")
# Compare the updated contents with the existing source path sln, if it
# exists and is the same we don't want to disturb VS by touching it.
set(sln_srcpath ${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}.sln)
set(old_content "")
if(EXISTS ${sln_srcpath})
file(READ ${sln_srcpath} old_content)
endif()
if(NOT old_content STREQUAL sln_content)
file(WRITE ${sln_srcpath} ${sln_content})
endif()
endif()
What would be helpful is if cmake had a way to run post generation scripts, but I couldn't find one.
Other ideas that didn't work out:
wrap cmake inside a script that does the same thing, but:
telling users to run a seperate script isn't simpler than saying to run cmake twice. Especially since needing to run cmake twice isn't a foreign concept.
put it in a pre-build step, but
building is common and changing the build is rare
changing the solution from builds inside the IDE makes it do... things
use add_subdirectory because that's suppose to finish first
it appeared to make the vcxproj's immediately, but not the sln until later, but I didn't try as hard because this adds a bunch of additional clutter I didn't want - so maybe this can be made to work
I need to search through all sub directories of a directory and find all files containing a "VERSION" string including a number.
I need to increment this number, so 1.1.2 will be incremented to 1.1.3 etc. and save it in the file again.
I need to run this on Windows machines only, if it makes any difference.
Can I do this with cmd commands or do I need to use a program for this ?
I would like to run this without installing anything if possible.
I ended up writing a Java program to go through the entire structure.
I found that using CMD commands was too complicated for me to structure, and using a Java program I could also easily reuse parts of the program in different but similar structures elsewhere in my file system.
The CMD usage could my the files for me, but extract a single line, manipulating it and putting it back inside the file was not easy using CMD commands, where as using Java was much easier.
I have a library which includes samples of how to use the library along with unit tests.
I'm trying to create custom VS2012 solutions that will be in the deployment.
Depending on input given when initiating the deployment, I want to be able to create a solution - e.g. Samples.sln - which includes projects specified in the input file.
Example:
//inputfile1.txt
ProjectA
ProjectB
I run an MSBuild xml file or an F# script (or anything that can do this) and I get a Samples directory with a Samples.sln containing ProjectA, ProjectA.Tests, ProjectB, ProjectB.Tests
A similar thing would happen if I gave an input file with ProjectX & Project7... etc.
With MSBuild, I've figured out how to read the file input, copy project folders to a new folder, and do some other things I would need for this whole process but I can't figure out how to create and customize a solution. I'm not sure this is even possible with MSBuild - I think I can only alter an already existing solution (but I've had trouble doing this as well).
I figure I have these options:
A. Add all projects to a Samples solution, then use msbuild to turn them on or off
or
B. There exists some other way (not using msbuild) to do this whole process
Is msbuild even capable of A?
You should understand that MsBuild mainly is a build platform. It also happens to be able to read and write file etc but that's not it's core business. So while you can generate solution files for it, it's going to be pretty hard using just MsBuild as it's simply not meant to be able to do things like that directly.
Here's an option C: if you open an sln in the text editor you'll see the structure is quite straigtforward: for every project there's a Project ... EndProject. You could generate these strings in the proper format (that is, genareate guid, figure out relative path to solution, get project name from path, ...) in an MsBuild target, put all of them in an ItemGroup then write it to a solution files using WriteLinesToFile. Perfectly possible, but a lot of work and I wouldn't recommend it.
For your option A, that's even harder: to include/exclude projects from a build, VisualStudio uses the .suo files and those are in some binary proprietary format which I have no idea how to generate.
That leaves you with option B which is basically option C but without reinventing the wheel: find a tool that can generate solution files for selected projets and have MsBuild invoke it useing Exec. There are probably a bunch of tools that can do this, but here's an example using the first usable one I found on the internet called SolutionMaker. Suppose your projects are in directory Foo, you'd use it like this:
<Exec Command="SolutionMaker /s Foo/foo.sln /p Foo /v 2012"/>
since the corresponding command line options are
/s <solution>: Solution file path
/p <path>: project root path
/v <fileVersion>: New solution file will be generated in the specified format.
valid versions: 2008, 2010, 2012.
I downloaded a set of source code for a program in a book and I got a makefile.
I am quite new to Linux, and I want to know whether there is any way I can see the actual source code written in C?
Or what exactly am I to do with it?
It sounds like you may not have downloaded the complete source code from the book web site. As mentioned previously, a Makefile is only the instructions for building the source code, and the source code is normally found in additional files with names ending in .c and .h. Perhaps you could look around the book web site for more files to download?
Or, since presumably the book web site is public, let us know which one it is and somebody will be happy to point you in the right direction.
A Makefile does not contain any source itself. It is simply a list of instructions in a special format which specifies what commands should be run, and in what order, to build your program. If you want to see where the source is, your Makefile will likely contain many "filename.c"'s and "filename.h"'s. You can use grep to find all the instances of ".c" and ".h" in the file, which should correspond to the C source and header files in the project. The following command should do the trick:
grep -e '\.[ch]' Makefile
To use the Makefile to build your project, simply typing make should do something reasonable. If that doesn't do what you want, look for unindented lines ending in a colon; these are target names, and represent different arguments you can specify after "make" to build a particular part of your project, or build it in a certain way. For instance, make install, make all, and make debug are common targets.
You probably have GNU Make on your system; much more information on Makefiles can be found here.
It looks like you also need to download the SB-AllSource.zip file. Then use make (with the Makefile that you've already downloaded) to build.