I have looked at build result for a simple hello world console app to see command line for compilation. Why is it so complex ? How can I then automate things if it is such complex ?
If you intend to automate builds of Xcode projects, use xcodebuild(1).
Your xcodeproj file contains all of the settings that you would need to specify on the command line if you were to call gcc directly. If you run xcodebuild all you need to do is specify your xcodeproj file, the target, the configuration, and the SDK to use. Everything else is done automatically.
Run "man xcodebuild" for more information.
XCode specifies an immense number of command line options for the compiler and linker with fully qualified path names. When working at the command line you'll frequently use defaults instead of specifying all the options the IDE does. Make or some other build tool is your friend for automation.
Related
Due to:
extensive usage of code auto-generation (notably for the .isa instruction and decoder sublanguage)
scons symlinking sources into the build tree, and in particular symlinking src/arch/ARCH to src/ARCH
it becomes very hard to setup Eclipse to work well with gem5.
Has anyone managed to achieve a good setup? Especially interested in Linux hosts.
I have achieved a very good setup with the following horrendous hack: define the Eclipse project inside the build/ARM directory itself!
This is done by creating a "New makefile project with existing code" in the build directory. You will also want to fix the C++ standard library as mentioned at: How to solve "Unresolved inclusion: <iostream>" in a C++ file in Eclipse CDT?
This works amazingly because the way the gem5 build system works as of May 2020, the build/ARM directory contains exactly the final compilation tree, including all the source symlinks and autogenerated code,.
This setup is not perfect because there is still some C++ stuff in build/ outside of ARM, e.g. ext, but 99% of the time we don't care about those, and I can perfectly navigate key autogenerated code such as instructions and decoder.
I then just build via the command line normally with scons.
Humongous autogenerated files like exec-ns.cc.inc turn on Eclipse's large file limited mode. Notably, if you want to jump to a definition, Ctrl + click does not work for me, so I just copy the symbol of interest and Ctrl + Shift + T to go to its definition.
I don't usually bother to try GDB step debug gem5 through Eclipse and use it mostly for code navigation, since GDB Dashboard tends to work well enough for me, and I often need to do new log collection runs and I sometimes use reverse debugging when things get serious.
But I have tested step debugging through Eclipse, and it did work normally (no reason not to I guess), you just have to set it up in exactly the same was as for any other C++ application with a Makefile, i.e. basically tell eclipse the Binary name and the desired CLI on the debug configurations.
You have of course as usual to choose between a gem5.debug debug build or a gem5.opt build, where the .debug build is about 10-20x slower but gives greater debug visibility. In general, if the time to reach the point of interest in a debug build starts to annoy you however, what you tend to really want is to do use reverse debugging.
This is also mentioned at: https://cirosantilli.com/linux-kernel-module-cheat/#gem5-eclipse-configuration
Tested in Eclipse 2020-03.
Trying investigate how to create "Hello world" on different languages via HaxeDevelop. I'm newbie and may be inacurate at terminology.
1) C# project. Pressing F8 gives me error:
haxe -cp src -cs D:/Programs/Projects/CsTestHaxe/bin/ -main Main
Unix.Unix_error(8, "mkdir", "D:/Programs/Projects/CsTestHaxe/bin/")
Build halted with errors (haxe.exe).
Via googling pretty much outdated info at least found solution:
haxe -main Main -cs out
And it works but ouput go to "src" location which is bad. Next googling led me to "Custom build" and using .hxml with pre-build command at project settings.
But why default template/settings not works for such simple thing as "Hello world" (used cs.system.Console)?
How default build may be fixed / probably I've installed or setup something wrong via HaxeDevelop installation?
2) C++ project. Pressing F8 gives me error:
Warning: Could not find environment variables for Visual Studio
Missing HXCPP_VARS
Error: Could not automatically setup MSVC
Error: Build failed
Build halted with errors (haxe.exe).
Using command line (similar to C# above) I can exucute C++ sources, but cant compile it.
Installed Visual Studio Community 2017. Nothing changed, same error. VS provide different own parts for installation. Should I install any specific?
Found also many threads about OpenFL workaround for C++ compilation. But I needn't OpenFL and want to use default Haxe API and tools.
Also OpenFL and C++ always mentioned with Lime. Do I need it too? Installed Lime via command line. But seems nothing changed.
3) Am I right that HaxeDevelop not yet support HashLink?
And if possible couple words about why HashLink appeared if there is Neko affiliated with Haxe?
As a result here an additional question: is it right that Haxe during compilation to target platform only "convert" .hx source to target one and then using third party (target platform) compile?
1) C# project. Pressing F8 gives me error.
This appears to be a known Haxe issue. Since it's been fixed on the dev branch, you could try a nightly build from build.haxe.org. Alternatively, you could also try manually creating the bin directory, since that seems to be what the error is about.
2) C++ project. Pressing F8 gives me error:
The latest Haxelib release of hxcpp (3.4.64) does not support Visual Studio 2017 yet. You could use a development version by installing hxcpp from GitHub, since again, it should be fixed there:
haxelib git hxcpp https://github.com/HaxeFoundation/hxcpp
The alternative is to downgrade Visual Studio.
Also OpenFL and C++ always mentioned with Lime. Do I need it too?
Yes, if you want to use OpenFL, you also need Lime, as OpenFL depends on it.
3) Am I right that HaxeDevelop not yet support HashLink?
Actually, a HashLink project template was added. But to follow the general theme of this answer, it seems it hasn't made it into an official relase yet. You can get a nightly build from here.
And if possible couple words about why HashLink appeared if there is Neko affilated with Haxe?
There is a two-part blog series on haxe.org by HashLink's author: part 1, part 2. The first part has a paragraph talking about this exact topic. Here's an excerpt:
First, let me explain the reasons for writing another virtual machine in replacement of Neko.
[...]
Back then, the Neko virtual machine was not especially designed to run Haxe and suffered from some limitations, the main one being performance.
[...]
And to your final question:
is it right that Haxe during compilation to target platform only "convert" .hx source to target one and then using third party (target platform) compile?
That is true for some targets, but it depends. For C++, C# and Java, Haxe indeeds generates source code for the target language and then invokes the target-native compiler after doing its own compilation (this step is usually called "native compilation").
However, some targets produce byte code directly (SWF and Neko), so there is no native compilation step there. Other target languages are interpreted (JS, PHP, Python and Lua), so there's no native compilation step there either. For HL it actually depends, there is HL/Jit (byte code) and HL/C, which is compiled to native C code.
You can find a comprehensive list of Haxe targets an their characteristics here.
Phew, that was a lot of questions in one. ;)
Simple question. How do I set the build configuration to something other than Debug?
Setting /P:Configuration=Staging in the Command line parameters box, leads to this error:
TeamCity says to use "Build Parameters" instead of "/property:" in an MSBuild step. What does that mean?
So how is it done? I need to build MSDeploy packages for all configurations, I can get the packages to build but everything is Debug.
The way you're doing it is fine -- although perhaps use a lowercase /p:. Our team does it this way too. TeamCity isn't throwing an error, it's just trying to provide some helpful information.
JetBrains provides some documentation for its preferred method at the bottom of the page under Using System Properties in Build Scripts.
I'm using CMake to generate my makefiles and VC solutions. I have my program running on linux just fine. I'm using a bunch of libraries, e.g. Lua. On my linux computer I just link to them and make sure in include the headers. All of the .so files are in some standard place. On Windows though I'm not sure what to do. Should I just include the entire Lua project into my own repository and link to that instead? Do I install Lua to some standard place like c:\program files\lua5.1 and link to that? Something else?
Your libraries can be in any place, you just need to say - where are they.
Before running cmake set up pathes of all your extern libs with some .bat file:
set LIBRARYPATH =path\to\your\library\
set include=%include%;%LIBRARYPATH%\include
set lib=%lib%;%LIBRARYPATH%\lib
Start cmd, run this .bat and then cmake should find all
I would provide a configuration field/variable for ccmake that the user can or must specify.
The mark_as_advanced can be used to make a custom variable only appear in the advanced mode. This would be suitable if you have a standard path (as you have mostly on windows). Yet, it still let's the user specify the value if needed.
Or you can simply set a variable the with the 'set' command if you don't want it in advanced.
Just make sure you check if the users entered a valid value.
I am using a Mac and would like to create a simple objective c unit test file to try out with a continuous build process. What is the simplest unit test file that I can create that I can point xcodebuild at to execute from the terminal?
//Simple file
//with some setup and a simple assert equal statement
> xcodebuild ...
A simple OCUnit test file might look like this (in a SimpleTests.m file)
#interface SimpleTests : SenTestCase {}
#end
#implementation SimpleTests
- (void)testFail { STFail(#"Tests are running"); }
#end
I've no idea if it is the simplest (and don't really want to know, thanks). It's certainly simple enough.
However, to get it to do anything you must build it into a framework that links against SenTestingKit and Foundation frameworks - so having your simple test file isn't really half the problem.
This might help
http://cocoawithlove.com/2010/09/minimalist-cocoa-programming.html
If you go with xCodeBuild you obviously need a complete XCode project, properly setup, inorder to build the framework. You could not really describe this as a simple, single file solution that you can build and execute.
It depends somewhat on what unit testing framework you choose to use. Creating a file with OCUnit should be the simplest since the framework is built into Xcode, and Xcode ships with templates for creating test files. You should be able to create a new OCUnit target from template, and then add an OCUnit file from template to that target. At that point you should be able to xcodebuild that target and be done.
That said, it's been a while since I used OCUnit, and I found using it from the command line and in our CI builds to be frustrating.
It's not built into Xcode, but Cedar has templates for creating new projects and files in Xcode. I wrapped up the xcodebuild command line in a Rakefile to make running from the command line easier. You should be able to create a new Cedar spec project from template and run it, but I see now that I've forgotten to include the Rakefile in the template. This should work if you get the templates sometime later today.
The Rakefile is for rake, which is a ruby version of make, in case you haven't used it. You can install it easily with
$ gem install rake
and then simply invoke tasks by name:
$ rake specs