I've created a monotouch project in monodevelop, and if I open it with notepad(or whatever that is in OSX), I can see the msbuild file import tasks from
Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets"
and
Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets"
Where are these files located in OSX?
I'm trying to understand how the build process work in monodevelop to make it behave as I want.
I probably do not need to modify those files, but I want to understand how those files are.
On Mac, assuming you're using the default Mono framework installer, and assuming the project has a ToolsVersion of 3.5, $(MSBuildToolsPath) and $(MSBuildBinPath) are both /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/3.5
However, these don't actually apply to MonoTouch, for two reasons:
MonoDevelop currently uses its internal build engine by default, not MSBuild/xbuild. The MSBuild engine can be enabled in MD preferences but is experimental, and only works for projects with supported targets.
There are no MSBuild targets for MonoTouch projects yet. This is planned to be fixed as MD gradually migrates to full MSBuild support, but when it is, the imports will be changed to import MonoTouch-specific targets.
You can see the MonoDevelop side of the MonoTouch build code in the MD source repository.
Related
While exploring about the platform setup for OpenCASCADE, I came to know about WOK commands which arent needed for CMake build system to use with OpenCASCADE
However another option of genproj tool (for which I havent yet found any exe but DLLs..) to be used with MSVC+ in built compiler so that we dont need any gcc installation
Whats the difference between the twos and which one is better and easier??
Also suggest me how to download and install and setup genproj on windows
OCCT project provided the following build systems:
CMake. This is the main building system since OCCT 7.0.0.
It allows building OCCT for almost every supported target platform.
WOK. This was an in-house building system used by OCCT before 7.0.0 release.
The tool handled classes defined in CDL (CAS.CADE definition language) files (WOK generated C++ header files from CDL) and supported building in a distributed environment (e.g. local WOK setup builds only modified source files and reused unmodified binary / object files from local network). WOK support has been discontinued since OCCT 7.5.0 and unlikely will be able building up-to-date OCCT sources (although project structure remains compatible with WOK).
genproj. This is a Tcl script allowing to generate project for building OCCT using Visual Studio (2010+), Code::Blocks, XCode and Qt Creator. This script has been initially extracted from WOK package (where it was implemented as command wgenproj in it's shell) and now maintained independently from it.
qmake. Experimental adm/qmake solution can be opened directly from QtCreator without CMake plugin (the project files will be generated recursively by qmake). Although header files generation (filling in inc folder) still should be done using genproj (qmake scripting capabilities were found too limited for this staff).
genproj doesn't require any DLLs or EXE files - it comes with OCCT itself and requires Tcl interpreter. On Windows platform it can be executed with genconf.bat and genproj.bat batch scripts in the root of OCCT source code folder. At first launch it will ask to put a path to tclsh.exe.
While CMake is the main building tool for OCCT project, genproj remains maintained and used by (some) developers - mostly due to personal habits and hatred to CMake. They differences of genproj from CMake that could be considered as advantages in some cases:
Generated project files can be moved to another location / computer without necessity to re-generate them.
Simplified 3rd-party dependency search tool genconf with GUI based on Tcl/Tk.
Batch-script environment/configuration files (env.bat and custom.bat), although CMake script in OCCT emulates similar files.
Generated Visual Studio solution contains Debug+Release and 32bit/64bit configurations.
Running Draw Harness and regression tests can be started directly from Visual Studio (without building any INSTALL target).
No problems with CMakeCache.txt.
Limitations of genproj:
No CMake configuration files. Other CMake-based projects would not be able re-using configuration files to simplify 3rd-party setup.
Regeneration of project files should be called explicitly.
Out-of-source builds are not supported (however, each configuration is put into dedicated sub-folder).
No INSTALL target.
No PCH (pre-compiler header file) generation.
It should be noted, that several attempts have been done to make compiler / linker flags consistent between CMake and genproj, but in reality they may be different.
After a hiatus of a couple of years I'm picking up Android development again.
I installed the newest Android Studio(4.1.1) with the latest Android SDK version (Android 11, API 30). After that I created a new project with gdx-setup.
If I add the old java source to my newly generated project I get this error:
error: package com.badlogic.gdx.backends.android does not exist
I'm not sure how to add this jar into the new project. In the Gradle configuration I see mentions of the backend, but it's not available.
I also downloaded the 'gdx-backend-android.jar' from the nightly build and put the jar in the Android library folder, all to no avail.
Does anyone actually know how to correctly add this dependency into my project?
I added the jar but still have an error, don't mind the other errors, I first need to fix the GDX import.
The project dependencies are managed by Gradle, so there is no need for you to directly touch any .jar files at all.
The most likely issue you're facing is that you are trying to use Android-specific classes from the core module, which is platform agnostic.
In a typical libGDX project, you do almost all your game code in the core module so it can easily be compiled for any platform. The code you showed above would be in the android module, but your LiveWallpaperStarter class would be part of core.
Some might say there's no reason to use core at all if you're making a Live Wallpaper, since it can't run on any other platforms besides Android. But there is some advantage in keeping the rendering in core so you can test in a desktop game window, because you can more rapidly compile and run on the desktop. This library has some tools that make it easy to wrap your rendering code in a class that lets you simulate a live wallpaper on desktop, for testing.
I created a haxe project using openfl. I can build and run the project on my own desktop using lime test windows.
Now how do I actually ship this project to other users?
I tried simply zipping the binary output created by running the command above. When I then unpack this zip on a different computer and start the executable file it will complain that I'm missing certain .dll files (more specifically the libstdc++-6.dll file).
Although this is not a direct answer to your question, a solution to this issue would be to compile through another software/tool, such as FlashDevelop.
For a few versions already, FlashDevelop includes an App manager feature that allows you to easily install the latest versions of Haxe, Lime & OpenFl (in an all-in-one package), and compile for all the Haxe/Lime/OpenFl targets seamlessly by just switching a value in a drop-down menu.
This allowed me to compile without any problems native C++ or Neko versions of my projects, thus embedding all the necessary files that could be zipped and sent to other computers.
I have a Visual C++ library which I want to compile for a certain platform (I try to compile POCO for a Win CE ARM platform, but that might not be relevant to this question). I got a vendor-specific Windows CE SDK (including all common Windows include files e.g. winbase.h) which is set as target platform within the Visual Studio project files. However, when I compile the program, I can see from the error log that the default Windows 6.0A SDK is used, resulting in a bunch of compilation errors.
I guess the WindowsSdkDir ist not set accordingly - I thought this would be automatically overriden when setting the target platform within Visual Studio.
So my question is: can I modify the WindowsSdkDir for a single project explicitly?
Thank you in advance
Which CE version, which VS version and on which Windows version? I know that I had problems installing CE5 and/or CE6 SDKs and getting them recognized by Visual Studio 2005 running on Windows 7 (64 bit). I don't remember the exact symptoms and fix, but you can test that by simply creating a smart device project for the target SDK.
If that is not the issue, there is also the pitfall with the target in both the project file (.vcproj) and the solution (.sln). You can change both independently from each other, up to the point where you compile the x64 debug version of a project in the win32 release version of the solution. Verify that these setting match.
Then, if you adjusted the .vcproj file to use your target platform (for which I personally would use a text editor), things should work. If you need to adjust the build or some paths, you can sometimes get by with e.g $(Platform) in the compiler/linker settings.
Lastly, if all that doesn't work, there are property sheets, which can adjust certain settings. You then create a property sheet once and then load it into the project that you want to compile. I'm not sure if you can change the target platform or the SDK paths with that approach though, and I'd rather try to find out why the SDK doesn't work and how to fix it instead.
I have had quite the experience trying to compile wxWidgets on Windows for x64. After a nightmare setting up Visual C++ 2008 express to compile x64 apps, I opened the wx.sln file. (I'm using wxWidgets 2.9.0, by the way.) I picked the Release configuration and set x64 as the platform. When I hit build, I get a slew of errors saying that wx/setup.h is missing. It would seem like the file is not being created. The real mystery is that the above steps work perfectly for wxWidgets 2.8.10. Any idea why this does not work?
Ensure that you have the file include/wx/msw/setup.h (in particular, it wouldn't be there if you checked sources out of svn). Other than that also check that you use vc9 versions of the project files just to be sure that you don't run into some import problems. With these projects all the necessary setup.h under lib/vc_lib (or vc_dll) directory should be created automatically by custom build steps in the projects.