I have a few different projects that all get mixed and matched into different types of solutions.
For projects, I currently have
EngineProj: c++, built as a .lib
GameProj: c++, built as a .exe
EditorProj: c++/clr, built as a .exe
For solutions, I currently have
Game: c++, built with EngineProj and GameProj
Editor: c++/clr, built with EngineProj and EditorProj
This has worked great for games. I have been able to make a few different game solutions that keep reusing the shared EngineProj.
The Editor solution has EditorProj build a .exe with a WindowsForm object called EditorForm. This is used to edit generic game data that is common for all game solutions.
Now, though, I want to be able to do the same thing for my Editor that I do with my games. I want to be able to make game specific versions of the Editor that reuse as much project setup and code as possible. Here is what I am working towards.
For projects, I am planning
EngineProj: c++, built as a .lib
GameCoreProj: c++, built as a .lib
GameExeProj: c++, built as a .exe (a very thin and small project)
EditorCoreProj: c++/clr, built as a .lib
EditorGameExeProj: c++/clr, built as a .exe
For solutions, I am planning
Game: c++, built with EngineProj, GameCoreProj, and GameExeProj
GameEditor: c++/clr, built with EngineProj, GameCoreProj, EditorCoreProj, and EditorGameExeProj
I am having troubles getting my GameEditor solution to come together.
The idea is for EditorCoreProj to provide the same EditorForm that EditorProj did; only in a .lib instead. EditorGameExeProj would then build with GameCoreProj.lib and EditorCorProj.lib. EditorGameExeProj would support a new WindowsForm object that derives from EditorForm, but implements new features unique to the needs of GameCorProj.
Various forms of unresolved externals have been plaguing me for a couple days now.
It seems that my issues stem from the fact that EditorCoreProj is a c++/clr project.
I read many articles and tried many different approaches, but eventually I found some reading that suggested that making a .lib would never work. It sounds like c++/clr .libs are not supported.
So, then, I tried making EditorCoreProj build as a .dll. For hours, I tried to get EditorGameExeProj to import the .dll. I read that maybe I need to tag everything for export and import. That sounded like a lot of work, and so I started just making some test solutions. However, that continually resulted in unresolved externals, too.
I am pretty new to making a .dll; I have always preferred .libs. Maybe I am just encountering newb issues with .dlls. At this point though, I have spent a couple days trying to get this setup.
And so, finally, my question.
Am I headed in the right direction? Maybe there is something much easier I should be doing?
Thank you for your time
I ended up sticking to the plan, and got everything working. I don't know if there was a better route to take, but this does full-fill all of my needs.
Related
I'm writing a strategy game in XNA and VB.NET. This technology combination looked like quite a good choice, right until I decided I would like to switch to MonoGame (but keep my game logic in VB.Net intact).
The problem is that MonoGame currently does not support VB.Net. I did some research and it seems I have basically two options:
Rewrite my code to C#
Write a small C# wrapper around MonoGame and turn my Game Logic code into a library
Needless to say, both of these options suck. Am I missing another option here? I don't mind giving considerable effort into making this thing work in MonoGame, but rewriting just isn't an option.
My findings so far:
While browsing the web, I stumbled across a MonoGame template for VB.Net. While it looked to be just what i needed, it crashed upon loading even after running a plain new project. I then proceeded to google for the error, but got nowhere near running the thing.
To explain my technology choice (because someone will ask):
Why XNA? I used it before, I'm familiar with it and even though it's outdated, it suits my needs perfectly and should still work for a couple years.
Why VB.Net? I have huge experience with it and I prefer it's syntax over C#. This is important to me since I'm writing a rather large-scale strategy game and keeping the code clean and understandable is essential.
Why not C#? Experience. I worked with C# for a little over a year, but it ain't natural yet. VB is.
I found a solution. A failry painless way to make this work was the MonoGame template I mentioned earlier. There are several small issues with that approach, but nothing too problematic.
Issue #1: Error when starting MonoGame Project.
After running a new VB MonoGame template project, a nasty error is thrown upon startup (System.TypeLoadException in mscorlib.dll). This happened since the template reference an incorrect version of MonoGame library (I'm using windows and there was an android library linked to the project).
Solution: Remove the MonoGame reference from your new project, and use browse to add back the correct version.
Issue #2: Content project missing in MonoGame.
MonoGame does not have a Content Project, but rather a folder called 'Content', which honestly behaves just like the project. Just add all your content from the XNA content project to this folder and it works. Amazing!
What it failed to do however is loading sounds and fonts from uncompiled content files (e.g. myFont.spriteFont). For MonoGame content, sound and font files had to be replaced with their compiled version from the XNA project.
Plus there is one small nuisance - each content file must be marked as 'Copy always' or 'Copy if newer' (default 'Copy Never'). I didn't really find a way to change this for all of them at once, but it doesn't take that much time.
Issue #3: XNA project was automatically resolving imports.
XNA project had one 'Syntactic Sugar' advantage. I never realized it until i switched to mono, but I never saw a single line called 'imports' in my XNA project. I made massive use of this, having many small classes which consisted only of few lines and used a 'list' of 'Vector2', etc. After porting to MonoGame I had to go through several hundred compile errors due to missing imports.
I'm still wondering whether this was caused by the XNA project or some other config in Visual Studio itself, but I must say I liked it. If you know something about this, please do share.
Conclusion:
Looking back, the process of porting to MonoGame took me about a month to figure out - but when I finally had all the pieces, the entire process took about 4 hours for 100+ source file + 100+ content file project. I'd say the guys at MonoGame did a tremendous job, and so did the gentleman who modified the template to work with VB.Net.
I have created a number of re-usable classes that I use across xcode projects, for example:
Utility
EmailController
MarketingController
FlashLightController
etc
I had been simply copying these class files from and back into a central repository, but now I have a number of apps it is all getting a little confusing from a config management point of view. So I was looking for an alternative.
I started investigating Static Libraries but they seem to be quite a lot of more effort for simply re-using code (e.g. different libs for device vs simulator, still having to have copies of .h files, etc).
Does anyone know of a decent alternative for quick and easy code reuse?
Thanks, Charlie
You can put the code files into a project without actually copying them into the project. In other words, just keep the class files in a completely separate location. Import them into many projects, but uncheck the option to copy them in. The projects will still refer to them successfully. Now a change made in the class files will propagate to every project that uses them.
Also, consider whether workspaces will help you.
In my view, almost anything is better than making a library or framework!
Static libraries would probably be your best bet, as I have used them and have found them to be pretty easy to use. (I haven't had to use different libraries for device or simulator, mine works on them all). Having the header isn't that annoying, and static libraries are really the only way (outside of dynamic libraries, which are banned by apple) other than copying the files to reuse code.
I'm currently trying to compile an old program (made with C++ builder 2 or 3) with the "current" Embarcadero RAD Studio XE2.
So, I was wondering whether there is an easy way to use the old code, as Borland once claimed to be fully compatible to lower versions... however I couldn't find a "project-file", only source-code (.cpp, .h, .res, etc.).
I tried to "add to project" the main .cpp, however there seem to be some wrong include-paths... it also seem to use the OWL-package and includes its important source-files...
I'm a bit confused which type of main project I have to open first, since you need to open a new project before adding the source to it. As the running .exe has a GUI, I tried a Form-Window first, but it may be better to use a console or service as the real form is produced within the code as far as I understand.
So, after installing OWL and correcting the include-paths, do you think it should be running fine? Or is there something else to take care of?
If your old project was using OWL, you're probably well outside of the supported upgrade path.
That being said, valid C++ code should still compile and work and I've heard of people using OWL with recent versions of C++Builder. (via OWLNext)
Regarding your confusion as to which type of project to use, I believe a console application would be your best bet. A forms application is completely wrong, that will bring in the VCL and give you no end of problems trying to reconcile the different windowing systems. A service application is a completely different beast as well, and isn't meant for GUI applications. A console application should work, but you'll need more. The OWLNext project has a wiki that should help quite a bit.
I have a library that I created which I would like to use the included classes across a few different projects while maintaining the library code independently. I would also like to be able to easily share it with other developers and have them easily implement it. At this point it doesn't need to be a static library.
What is the best method to do this? I have seen other devs put their classes in a brand new XCode project then import that, but what is best practice?
I think the best practice is to create a project with a static library target. Other developers can include it as a subproject in their projects.
Second best would be to simply make a directory of source files that can be included in a project on an as-needed basis. This is useful for general purpose utility code where a particular project may not want all of it.
In both cases, the library code should belong to its own git repository and included in a project as a git submodule.
If it will ever become a static library, it's best to make it one now, rather than waiting until it is "ready"; by the time you decide to switch it over, a few projects will already be using it, and converting each of them to use it will be a pain. Just do it the right way from the beginning.
If you want to distribute the library without source, you will want to use lipo to build a universal library that contains both ARM and x86 code. Unfortunately, Xcode doesn't make this as easy as it could be, but it's not too difficult with some light shell scripting.
As far as I know you should create a new project and that project to any other project you want use library in. Then link the projects and you can access it. The other way which I have done also, copy the library classes directly to the new project and access the library through importing the needed classes. In my case i found creating a project and linking it with the new project is the easiest. although copying the classes isnwhat we all do when using external libraries such as cocos2d. As far as sharing it with others, just upload it to github another place of your choice so it can be used by other dev's. I hope this helps you.t
I don't know how mature the code is, but since you specifically mention wanting to share it with other developers, you may want to investigate CocoaPods.
I've been working non-stop for the last three days on a completely managed interface to Erlang. At this point, I've decided that there simply must be an easier way. I've got a little over 3000 lines and it's not even in a compilable state yet. To be honest, I'm getting lost in my own code.
So, I then remembered that Erlang has a C library called erl_interface. Unfortunately, it only comes as a .LIB file, which isn't usable via P/Invoke. I'm now investigating ways to expose the static library through a DLL.
I'd like to stay away from Visual C++, mostly because I'm not a C/C++ programmer by nature and I find it really difficult to configure. TinyC is my compiler of choice when working with anything in C.
How can I go about this?
I know I can link erl_interface to a DLL, but how can I expose the functions? Do I have to essentially wrap each and every one of them in my own exports? That probably won't be a problem, since I could write a script to generate the code from the header file. But is there an easier way that I just don't know about?
Also, please don't recommend OTP.NET. It's a nice library, but I'm looking to use this is a large project, so I'd like to keep it in-house.
So, your problem is one of turning a static lib into a dynamic one.
The least-effort solution would be to write a thin shim file in 'C', that just delegates to the files in the .lib e.g.
ReturnType my_method1(args...) {
return real_method1(args...);
}
...
and build a DLL from that and the static lib.
Afterthought -- There is another approach you could take -- which is build the .lib into a C++/CLI assembly and do the transition/wrapping in that. It's what C++/CLi is there for, after all.
If you want some help with interfacing to Erlang with C, have a look at "EPAPI" (Erlang Port API) link text. You can of course browse the source code since it is hosted on Google Code. A DEBIAN repository is also available.