Task: Compiling and packaging Windows release

Everything about development and the OpenMW source code.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1150
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Github profile: https://github.com/lgromanowski
Contact:

Task: Compiling and packaging Windows release

Post by lgromanowski » 13 Aug 2011, 19:40

Star-Demon wrote: Okay. Help me understand this completely so I know top to bottom what must be done and how it must be done each time.

What problems does this task entail that make it different from the other releases?
What has worked previously?
How can we break this up into subtasks?
How can we find who can work on these subtasks?

I volunteer to help. I will need some guidance, though.
pogzy wrote: Hi,

The project build was created on Linux system, in Linux, packages are managed by the system, so the consistence between them is very hygh.

On windows side, all librairies used are ported from Linux, they have stand alone installs, the system does not tell you if they are consistent together.

This is a point.

Another point is the CMake system that is not as aware of windows library port as it is on Linux system.

A way to bypass this could be to rely on cygwin, which is a global port of Linux subsystem (gcc, libs and so on) on Windows, but perhaps at the cost of optimisation.
Perhaps Mingw could be used, I am not sure. But I think that Visual studio on Windows will produce the better exe.

I've tried to compiled the project, fine at the beginning even if I had issue with compiler paths of some files that I had to change, but now, I failed on some libs, CMake not finding Freetype, etc..

Don't forget, if we fix all building issues on Windows, each time a new lib will be added or change, it will be more time to integrate on Windows than on Linux. But if somebody is mastering the windows build, a wiki update is welcome.
athile wrote: Regarding compiling...

As pogzy says above, the lack of standard locations for external packages (e.g. FreeType, Boost, etc.) makes building on Windows more challenging. CMake tries to solve this problem...but doesn't do so completely.

One way to fix this is what I mentioned in another post. Basically create a zip of some sort that somehow acquires all the OpenMW dependencies (maybe stores them directly in the zip, or has a copy of wget.exe which automatically downloads the right versions) and places them in a fixed location relative the OpenMW build.

The zip could be a zip of pre-compiled libraries - which is simple, but can be a pain to generate since it needs a flavor (VS2008, VS2010, Debug, Release, etc.) for every set of compiler + build options.

The zip could contain the source for all the dependencies, but this can be a pain since the different packages can require different build steps (e.g. boost uses bjam) and may have dependencies of their own. (Though with some script file, hopefully some of this could be hidden from the developer.)

Lastly, they'd like need to be some CMake logic to look to see if this zip has been installed so it would know where additionally to look for the dependencies.

The above is not necessarily easy but it's certainly possible and once someone gets it right once, no one really has to worry about it again (or until a dependency is added/removed/changed, at least).


This is something I'd like to help out with, but it'll likely be in a couple weeks as I don't yet have a development machine - just a netbook.
Star-Demon wrote: You know. I wonder if this can be solved by having the windows package be an installer that contains packages that get installed as part of the install process...?

The problem that I see is that you only have certain rights when it comes to libraries, some can be statically linked, some can't, some in between.

It would be great if you could just throw it all into an installer, but that doesn't solve the compiling, does it?

Ahhh I see.

So - I guess what I'm saying is I like your idea, but obviously making something for each is a colossal pain unless we automate that process too, which also requires an investment from us in time.

Well, we could just decide to say "VSxx or nothing". But that is not really a great idea. What we need is a better way, even if it requires thought and planning at first.

Is there a way we can set that process up - that once we figure it out, where we only have to do it once and then feed future releases into it and it'll be done?

This is initially why I posted in the format I did. more or less, I believe that that method does give some insight when things seem very daunting or complex.

At any rate - we have time to think and look around for solutions while you get a new compy. We'll use that for the thinking and planning part.
pogzy wrote: I've build severall projects at work with Visual Studio and open sources lib and we diid like this :
we put the binaries and .h of the used lib into the repo in the right directory related to the project, oh yes, it is not CMake sexy build. But if any linux user can make Cmake do the job smoothly for any Window machine, I'll take it right away. Done like this, any newcomer just get the copy of the repo and it works.

The fact is that building under windows is not easy, CMake is not doing a good job. It could be much more easy if we have a consistent VS project with a fixed directory structure, even for libs.

Under Linux, libs are handled by the system, the user usually don't even know where they are, under Windows, for third parties libs (not windows ones), the user have to manage all by hand. So trying to think in a Linux style under Windows could be between pain and stupidity, as far as CMake is not working that nice ;)

PS : I do want to contribute, but I don't have too many time, so I will dive in the code only when all the building stuff under Windows will be fixed, because I don't want to lose my time in build issues.
Star-Demon wrote:
pogzy wrote:I've build severall projects at work with Visual Studio and open sources lib and we diid like this :
we put the binaries and .h of the used lib into the repo in the right directory related to the project, oh yes, it is not CMake sexy build. But if any linux user can make Cmake do the job smoothly for any Window machine, I'll take it right away. Done like this, any newcomer just get the copy of the repo and it works.

The fact is that building under windows is not easy, CMake is not doing a good job. It could be much more easy if we have a consistent VS project with a fixed directory structure, even for libs.

Under Linux, libs are handled by the system, the user usually don't even know where they are, under Windows, for third parties libs (not windows ones), the user have to manage all by hand. So trying to think in a Linux style under Windows could be between pain and stupidity, as far as CMake is not working that nice ;)

PS : I do want to contribute, but I don't have too many time, so I will dive in the code only when all the building stuff under Windows will be fixed, because I don't want to lose my time in build issues.
It's okay if you don't have a lot of time. We all have real lives, in some way. You've shed a lot of light on it, although sometimes it's hard to understand through language barriers. I find that challenge exciting, though.

See, I'm concerned that we may not be allowed to use all of our libraries like that.(Dynamic vs Static Linking?) If you say we can do that, though, then it's an option. Maybe I need to see it in action.

All the libraries and headers in a nice OpenMW folder, load the VS project, hit compile and the binary comes out. Would be nice. Things being easy is nice because it entices people to help in the future.
athile wrote:
CMake is not doing a good job. It could be much more easy if we have a consistent VS project with a fixed directory structure
I know it's a matter of opinion, but I actually have to disagree with the above statement. I actually find CMake is not doing a perfect job, but it's doing a better job than not using it. The auto-generated CMake .sln files strike me as far easier to maintain than a parallel, hand-maintained set of .vcproj files - especially when we start talking about multiple compiler versions (VS2008 and VS2010 do not use the same vcproj format).
we put the binaries and .h of the used lib into the repo in the right directory related to the project
This, on the other hand, I do agree with - with one minor exception :)

Building dependencies on Windows can be such a pain. It is likely easier to have a set of zips containing the dependencies, even if they have to be built for VS2008 debug, VS2008 release, VS2010 debug, and VS2010 release. As long as we're not modifying the actual source of those dependencies, the zips of binaries shouldn't have to be rebuilt often. Building from source would be ideal, but I'm not sure that it is realistic.

I don't think these binaries belong in the git repo, though. That seriously (and unnecessarily) bloats the size of the repo significantly (debug binaries can be huge) - and does so for every developer, not just the ones using that particular compiler. In fact, I suspect including Boost alone for just one compiler would likely push the repo size over the github free account repository size limit. I agree with the idea, but simply think these files should be distributed externally as zip packages to overlay on the repo.

I'm picturing a directory layout like this:
  • <omw root>\prebuilt\<flavor>\<component>
A couple notes:
  • The root .gitignore would need "prebuilt" added to ensure these files didn't get included in the repository
  • The "flavor" could borrow Boost's naming convention: e.g. vc90-mt-gd, vc90-mt, vc100-mt-gd, vc100-mt, etc.
  • The "component" directory next since not all components use a standard sub-directory for their includes, libs, and binaries. We probably want to include a version number which each component too, just to avoid mistakes (i.e. boost_1_42 and ogre_1_7_1).
  • There would be one zip per "flavor" and each one should likely contain the full "include" directory, etc. for each component - even though things like headers theoretically could be shared - just to keep things simple.
  • Lastly, I don't know CMake well, but I'm sure there's got to be a way to have it contain the necessary logic to say "if compiler settings == X, check for prebuilt/X, and if it exists, set OGRE_HOME, BOOST_ROOT, include the following headers, libs, copy the following binaries, etc.", otherwise use the usual CMake find logic.
Now all that remains is for me to stop posting on the forums and actually do this :)
Star-Demon wrote: It still needs to know how to find these things, which I'm not sure it does because not all of the installers for the libraries work (that's a big problem - see OpenAL's installer.), and not all clearly show the command to set the environment variable so Cmake knows where to find it.

I actually GUESSED one and Cmake found it afterwards. ( setx SOMEvariable path) I haven't had luck with guesses based on its output after that for others. I'm stuck on OpenAL because while I installed ffmpeg, I installed their installer, and installed, nothing came of it. For whatever reason, it didn't work, so we have to go back and solve that problem because unless you've already solved it yourself and share that with everyone, no one will know about it.

It'd be nice if each library installed and remembered correctly so Cmake and multiple versions of VC don't have to be troubleshooted like this.
athile wrote: The root OMW CMakeLists.txt, if it detects the prebuilt folder, can always supersede the CMake "Find" logic and just manually call include_directories() and link_directories() - no environment variables to worry about...unless, of course, it would be easier to set the environment variable.

EDIT: By the way, the find logic usually works by simply including a file from the directory "C:\Program Files\CMake 2.8\share\cmake-2.8\Modules". For example, I think I had to open FindOpenAL.cmake to figure out which environment variables to set.
Star-Demon wrote: Huh...

We should write all this into setup, at one point.

Anyways, I got Cmake to generate a project file. Let's see what happens when I open it and try to build. I'll get to see this myself.
athile wrote: Good news and bad news:

GOOD -

I got a successful Windows build. It required some code changes to openmw, openengine, and mangle as well as CMake changes to look for a "prebuilt" directory. I put together a prebuilt zip for Visual Studio 2010 Debug...and well, for the time being the added CMake logic looks only for that flavor.

The prebuilt binaries are downloadable here: http://www.megaupload.com/?d=95WMU54V. Unzip them to the folder within a "prebuilt" directory of the openmw source root and - if you're using VS 2010 - OpenMW should build with lots of warnings but no errors. (You'll still need to manually copy all the binaries like OgreMain_d.dll to get OMW to run, but the files are all somewhere within the prebuilt directory.)



BAD -

But openmw.exe crashes on startup. Perhaps it is Audiere? I thought I saw some other forum posts saying Audiere is not working. Unfortunately, Audiere is the only sound library (of the options) that had pre-compiled libraries available.


Nicolay, I don't know if you want to merge the source changes so everything simply compiles on Windows as a step in the right direction, or if you want to wait until it also runs correctly as well. Not sure how much time I'll have this week to pursue this further myself.
Zini wrote: Merging now would probably be good idea, if it is only a sound problem. If I remember correctly even the D version had quite a few sound problems on Windows, so we may not be able to resolve this quickly.

You can test your theory about Audiere causing trouble by running OpenMW with the --nosound switch.
athile wrote:

Code: Select all

  // Update all sounds
  void updateAll()
  {
    for(ManagedSound *s = list.getHead(); s != NULL; s=s->next)
      s->update();
  }
s is a garbage pointer. This gets hit despite the fact that I add "--nosound" as a command-line argument. The value is 0xFEEEFEEE, which I believe on Windows indicates freed memory (the CRT writes that pattern to all freed memory).
Zini wrote: Found it. *Ugh* A custom implementation for a linked list? There is no excuse for that, when the STL offers a reliable and efficient implementation. Grab a big stick and beat Nico until he starts fixing this. Or replace the custom list yourself.

Edit: After looking at the code a bit more, I am rather surprised that this happens with --nosound though, because --nosound disables the whole sound system quite efficiently. Doesn't look like a list problem (the custom list implementation is still a bad idea). Maybe a stack backtrace would help to find out what is happening here.
athile wrote: Zini, despite your unforgiving vehemence against custom list implementations, I don't think that actually is the root problem.

The problem (I believe) is that s->update() can result in the sound object removing itself from the sound manager list while the list iteration is occuring in updateAll(). A method down the call chain of update() can detach() the sound and thereby change the contents of that list - which in turn corrupts the current loop iteration.

The problem appears to be fixed by:

1) Changing to a container to a std::list<> (while we're there anyway)
2) Changing the loop construct to loop over a copy of the list

Code: Select all

SoundList tmp = list;
      for (SoundList::iterator it = tmp.begin(); it != tmp.end(); ++it)
          (*it)->update();

A list copy of course isn't the most efficient strategy in the world, but it does work. The "objects that remove themselves from their own containers" pattern can often lead to tricky gotchas (for example, this crash we're talking about) so I can't really dive into this one right now. There are various ways to fix this in the general case including changing the pattern entirely, having objects null out their entries in the list - but not actually remove them (let the manager sweep the list clean every so often at a safe time instead), or restructuring loops to grab the next iterator before the current item can remove itself (often works, but doesn't protect against new loops not doing this and re-introducing the problem).


Anyway, with the temporary fix in hand, I'm now on to a crash in my Intel Graphics Accelerator Driver. Ah, Intel, what wonderful graphics drivers you write :) My point being that it seems like the new crash is likely particular to my 0.1Hz, half-threaded netbook and not necessarily an OpenMW problem.
Zini wrote: Looks like this part of the code needs a complete rewrite. I suggest you push your fixes, so that Star can merge them and try it out on his box (I assume he has a more reasonable graphics hardware). That should tell us, if we are finally through with the Windows porting.
Star-Demon wrote:
Zini wrote:Looks like this part of the code needs a complete rewrite. I suggest you push your fixes, so that Star can merge them and try it out on his box (I assume he has a more reasonable graphics hardware). That should tell us, if we are finally through with the Windows porting.
http://xfxforce.com/en-us/products/grap ... lang=en-us

Yes. :)

It's alright to add athile as a remote, right? then when I "git merge upstream/????" it should pull from Athile?

Just say when, I just discovered myself that I'll no longer be using eclipse to quickly make classes for C++ anymore because the .cpp files aren't working correctly due to some kind of syntax error. Stupid CDT. God, I like eclipse, too. :( I'll put those on hold and focus on other things.

BUT! The compiler isn't complaining about my new files. That's a good start.
Zini wrote:
git remote add athile [url=git://github.com/athile/openmw.git]git://github.com/athile/openmw.git[/url]
git fetch athile
git merge athile/master
Star-Demon wrote:
Zini wrote:
git remote add athile [url=git://github.com/athile/openmw.git]git://github.com/athile/openmw.git[/url]
git fetch athile
git merge athile/master
Ah. I mixed it up. Thanks.
athile wrote: Temporary fixes of cloning the list applied to the sound update loop, changed the OGRE config to use DirectX rather than OpenGL, and - at a whopping 0.5 fps - OpenMW is running on my Windows netbook.

It's not perfect though since I still get a crash in OGRE at shutdown (during delete mRoot - looks like maybe a deleted object being referenced in the octree? Maybe?). But on a relative scale, it's still progress. Someone else is going to have to fix the crash at shutdown; compiling/debugging on a netbook is getting unbearable.

Feel free to pull my forks of openmw / openengine / mangle.
Star-Demon wrote: Got your branch - will give it a shot tomorrow night.
Star-Demon wrote: Annnnd here's what I got upon build:

Code: Select all

1>------ Build started: Project: MyGUIEngine, Configuration: Debug Win32 ------
1>  MyGUI_ResourceTrueTypeFont.cpp
1>..\..\..\..\openmw\extern\mygui_3.0.1\MyGUIEngine\src\MyGUI_ResourceTrueTypeFont.cpp(29): fatal error C1083: Cannot open include file: 'ft2build.h': No such file or directory
2>------ Build started: Project: openmw, Configuration: Debug Win32 ------
2>  openal_out.cpp
2>..\..\..\openmw\libs\mangle\sound\outputs\openal_out.cpp(7): fatal error C1083: Cannot open include file: 'AL/al.h': No such file or directory
2>  ffmpeg_source.cpp
2>H:\Development\Libraries\ffmpeg-0.6\libavcodec\avcodec.h(30): fatal error C1083: Cannot open include file: 'libavutil/avutil.h': No such file or directory
2>  soundmanager.cpp
2>c:\users\star-demon\openmw\libs\mangle\stream\servers\std_stream.hpp(34): warning C4244: 'return' : conversion from 'std::streamsize' to 'size_t', possible loss of data
2>c:\users\star-demon\openmw\libs\mangle\stream\servers\std_stream.hpp(46): warning C4244: 'return' : conversion from 'std::streamoff' to 'size_t', possible loss of data
2>c:\users\star-demon\openmw\libs\mangle\stream\servers\std_stream.hpp(53): warning C4244: 'initializing' : conversion from 'std::streamoff' to 'size_t', possible loss of data
2>H:\Development\Libraries\ffmpeg-0.6\libavcodec\avcodec.h(30): fatal error C1083: Cannot open include file: 'libavutil/avutil.h': No such file or directory
2>  Generating Code...
3>------ Skipped Build: Project: ALL_BUILD, Configuration: Debug Win32 ------
3>Project not selected to build for this solution configuration 
========== Build: 0 succeeded, 2 failed, 4 up-to-date, 1 skipped ==========
So - aside from my own OpenAV problem...I can get it built.

In order to solve this I need to find and assign libraries that aren't in the download. Do I have o build their source to get a library to do this after? I'm lost on this.

So, FFmpeg, SNDFILE libraries. Don't got em. It's just source.

SNDFILE? You mean this?
http://www.mega-nerd.com/libsndfile/
athile wrote: You're not compiling with my fork of mangle if you still have an "AL/al.h" error. See my version of openal_out.cpp: http://github.com/athile/mangle/blob/ma ... al_out.cpp. There's no "AL/al.h" in that file :)

openengine and mangle are both submodules which means they need to be treated as "separate" branches if you want pull in my changes. Switch to those sub-directories, add the appropriate remote branch (while in that sub-directory...you're now effectively working in an entirely different repository), and then merge that remote repository - similar to how you did it with the main openmw branch. (This took me a bit to figure out as well, since I too am new to git.)


Also, if you have my root CMakeLists.txt, it should be trying to use Audiere, not FFmpeg or SndLib....so I'm a bit confused if you still need those libraries. You might want to delete your CMakeCache.txt just in case. I'm pretty sure the 7z file has all the necessary dependencies - or at least based on the CMakeLists.txt logic I added.

Good luck :)
Star-Demon wrote:
athile wrote:You're not compiling with my fork of mangle if you still have an "AL/al.h" error. See my version of openal_out.cpp: http://github.com/athile/mangle/blob/ma ... al_out.cpp. There's no "AL/al.h" in that file :)

openengine and mangle are both submodules which means they need to be treated as "separate" branches if you want pull in my changes. Switch to those sub-directories, add the appropriate remote branch (while in that sub-directory...you're now effectively working in an entirely different repository), and then merge that remote repository - similar to how you did it with the main openmw branch. (This took me a bit to figure out as well, since I too am new to git.)


Also, if you have my root CMakeLists.txt, it should be trying to use Audiere, not FFmpeg or SndLib....so I'm a bit confused if you still need those libraries. You might want to delete your CMakeCache.txt just in case. I'm pretty sure the 7z file has all the necessary dependencies - or at least based on the CMakeLists.txt logic I added.

Good luck :)
huh...that's strange. Lemme clear everything out and start over. Could have sword all I had to do tonight was configure, generate, and open the project and build it? Did I forget something last night?

Be back tomorrow with more...
nicolay wrote:
athile wrote:

Code: Select all

  // Update all sounds
  void updateAll()
  {
    for(ManagedSound *s = list.getHead(); s != NULL; s=s->next)
      s->update();
  }
s is a garbage pointer. This gets hit despite the fact that I add "--nosound" as a command-line argument. The value is 0xFEEEFEEE, which I believe on Windows indicates freed memory (the CRT writes that pattern to all freed memory).
Sorry for the long reply time guys. You were right about this (in one of your later posts), it's just a matter of deleting an object while iterating it, just a small oversight on my part. Simply getting the next pointer before the update() fixes it. I've updated the OE repos, will get the OpenMW repo up to date soon.

EDIT: I've merged in your changes now athile. Star-Demon: it should be enough to do a pull on the main repo and do a git submodule update now.
nicolay wrote:
Zini wrote:
git fetch athile
git merge athile/master
Or simply

Code: Select all

git pull athile master
Pull does a combined fetch and merge, and only fetches (downloads) the branch you want, not all other branches the user might have.
Cyber-Kun wrote: As someone who is a huge fan of Morrowind, and can only play Morrowind on a Windows, this is great to hear.
Star-Demon wrote: I don't have access to the megaupload file with the files I need:

So this is as far as I can get with what I have on my own system:

Image

I don't have an avcodec or avformat library. I could really use those files. :(

But! I did update, but I'm not sure of the best order of operations for that, but I did it update and submodule update.

I think the next thing this weekend for me will be making some new outlines for certain wiki pages and hopefully getting em done.
nicolay wrote: IIRC ffmpeg (libavcodec and libavformat) was a real b*tch to compile on Windows, and finding a precompiled version was difficult (this might have changed.) I would probably recommend using one of the other options instead. I think Audiere worked very well with the first D versions that had sound, and even though it's not updated anymore, the SDK / DLL should work fine.
Star-Demon wrote:
nicolay wrote:IIRC ffmpeg (libavcodec and libavformat) was a real b*tch to compile on Windows, and finding a precompiled version was difficult (this might have changed.) I would probably recommend using one of the other options instead. I think Audiere worked very well with the first D versions that had sound, and even though it's not updated anymore, the SDK / DLL should work fine.
Cool, I'll see what I can do with that today.
Zini wrote: Well, another week has passed and we still don't have a release. I would really like to get this out of the way (also I would like to have something I can gloat about over there at the Redemption forum). Are there still major problems?
athile wrote: EDIT: Posted the file on DropBox: http://dl.dropbox.com/u/11152445/openmw-0.08-win32.7z. See posts below.

I fixed the crash at shutdown (SoundImpl was leaving a stale Listener on the camera) and made a pull request.

I put together a 7z of the Windows build if we want to call 0.08 "done". I'd appreciate if someone with a Windows machine would download it and make sure it works on more than just my machine.

I posted it to megaupload again since I'm not aware of a better place to host files (and don't have access to the SourceForge OpenMW files directly): http://www.megaupload.com/?d=8E8GOVIK
Cyber-Kun wrote:
athile wrote:I fixed the crash at shutdown (SoundImpl was leaving a stale Listener on the camera) and made a pull request.

I put together a 7z of the Windows build if we want to call 0.08 "done". I'd appreciate if someone with a Windows machine would download it and make sure it works on more than just my machine.

I posted it to megaupload again since I'm not aware of a better place to host files (and don't have access to the SourceForge OpenMW files directly): http://www.megaupload.com/?d=8E8GOVIK
I'll be home in two hours to get this thing tested.

Shame right now that the file on megaupload is, "The file you are trying to access is temporarily unavailable."
athile wrote: Any suggestions on alternate upload services? I've just been using megaupload because it doesn't even require you to register to upload.
heilkitty wrote: IMHO, Dropbox is suitable for this kind of thing (it requires registration though).
sir_herrbatka wrote: Use Dropbox.
athile wrote: Done.

http://dl.dropbox.com/u/11152445/openmw-0.08-win32.7z.

Hopefully that works.
amos wrote: Hi,

I just tested the build on a Windows XP machine (Direct3D9) and it seems to work fine, i got a cave level with music running and all. :D
Cyber-Kun wrote: It has loaded, and the cave works for me. I have sound, and I can go around the cave. No water, and the NPCs don't really exist. I haven't crashed but for when I try to open the door to the outside. Alt-Tabbing works fine. Spamming buttons also has not crashed me yet.

Is there anywhere else I can go? coc doesn't want to go anywhere.
Zini wrote: coc should work. Please note, that if a cell name contains spaces, you need to put it into quotation marks, e.g. coc "Balmora, Eight Plates".
Star-Demon wrote: DLing - will test tonight.

PS: Relax.
Star-Demon wrote: Okay - so: after unzipping the package from megaupload, I copied my backup data files folder into the openMW-0.08-win32 directory.

My system, just for reference:
Windows 7 - Ultimate
XFX radeon HD 5850
6 gigs system ram
Intel Core i7

4.7 gigs later I then clicked the app.

A console window popped with a directory outputted.
The ogre config screen popped up.
I selected Direct3d.
it CTDed.

So...I did it again.
Nothing.

So I deleted ogre.cfg and switched to openGL.

the screen flipped, then CTD.

then I renamed Data Files, which is the TES3 convention to Data, which is the TES4 convention.

it worked fine.

I could move around, see most objects. Lighting is on extra bright. NPCs were not all there, and in default position, music was running, sounds like fire and dripping were heard. the resolution is low, and I couldn't see water.

Also - screwed up position of windows and my gadgets. I had to reposition them.

Otherwise, it functioned, but I didn't have a console to play with it and look at other cells.

So - I say we got something, here.

Now - what is next on updating how we do this on windows? We have pre-built libraries now? Am I going to have an easier time and can update our wiki telling everyone that windows contributors are now very very welcome and have nothing to fear?

Once this library stuff is out of the way, and i can build what other people bring, that certainly goes a long way towards getting me into the coding with the rest.
Cyber-Kun wrote: Went to "Akulakhan's Chamber". Fog seems to be drawn as the skybox, no blur in effect as of now. Bridge also has some box that looks like the collision detection. The Heart looked ugly.

Went to "Mamaea, Shrine of Pitted Dreams". I think it sent me to the 0,0 location and I couldn't find the caves. Just the skybox. No crashes yet.
Zini wrote: All obstacles to the next release removed, it seems. What are we waiting for?
sir_herrbatka wrote: http://www.youtube.com/watch?v=25waL5oTWDI

:D

Well, no offense but the zini made good point. We are waiting for the Duken Nuken Forever or someone will list the things that are waiting to be done?
Star-Demon wrote:
sir_herrbatka wrote:Well, no offense but the zini made good point. We are waiting for the Duken Nuken Forever or someone will list the things that are waiting to be done?
A list would certainly enlighten me on what comes next, I'm not sure what it is Zini really wants.

Besides, we have lives, don't we? The weekend is coming. I'm sure we'll get it done very soon.
Star-Demon wrote: With that in mind, now - We're going to have to make some changes to the environment setup and other pages in the wiki.

Putting them in order, we'll have to get down what to download, where to put it, and how to direct Cmake on windows to read from the libraries we already built. That should be the weekend project.

What I'll try is downloading and throwing it all together and see if I can give it another shot by changing all the library settings and making a new project. I noticed Athile made a link of the pack on sourceforge and posted a link on the downloads wiki entry...so that's good.

We really have to update our instructions and reference stuff, though.
Zini wrote:
A list would certainly enlighten me on what comes next,
Unless I missed an important point, that would be an empty list. AFAIK we are done. That's why I was pushing the issue.
I'm not sure what it is Zini really wants.
The actual release? A tag must be added to Nico's repository. The Linux source package and the Windows binary need to be uploaded to SourceForge (though github own download hosting would work too). And we need at least an announcement in the announcement section of the forum.
nicolay wrote: Sorry, been away for a short while. Great to see the windows build up and running! I'm get to work on announcing the release.

EDIT: Done. BTW, just a question to git users: does the release version tags show up on your repos when you pull? (run "git tag" to see the tags - one of them should now be openmw-0.08 after pulling.)

I'm asking this because they don't show up in any of the github repos (except mine), but I suspect this is only because git push does NOT push tags by default, unless you give it the --tags switch.
amos wrote: Yes, I see the tag. You can check this on the github web page, if the tag was pushed it should show up under Switch Tags.
nicolay wrote: Yes, that's the deal: Yours is about the only one which has these tags in the 'switch tags' list (except mine.) But as long as people see them locally I guess that's the important part.
Star-Demon wrote:
Zini wrote:
I'm not sure what it is Zini really wants.
The actual release? A tag must be added to Nico's repository. The Linux source package and the Windows binary need to be uploaded to SourceForge (though github own download hosting would work too). And we need at least an announcement in the announcement section of the forum.
And it got done the next day. :)
Zini wrote: Actually the same day for us Europeans.
Star-Demon wrote: Ahhh...I'm in the US, so I went to sleep last night. For me, there was no rush. :)

Anyways, with the release done - again, there are more tasks inside that - What I meant before was that even at release there are steps to take. No, they aren't about the code, but about other things. Part of them is updating our written stuff so it's all usable- that'll be a good ting to do this weekend, maybe I'll bang some out later today, but I'm still really confused, considering the changes and how many threads they are in, about if we actually made grabbing source and pre-built libraries make building and coding on windows any easier from nothing to execute/run and debug?

I really need to get a straight answer, because what I'm reading may or may not suggest it's actually any easier. I really want a clear set that we can write into the wiki for everyone.

So - we have this package - and of course we have source, so - with this, what other steps are there to grabbing stuff and installing stuff are there? which ones did we eliminate? (compiling other people's libraries?)

So, if I were to update the windows section, It will go more or less like so:

Grab libraries that need includes (was this eliminated?)
Grab and install tools.
Grab source via git and make build folder
grab and throw in our prebuilts
Cmake config and generate project
Open VC, press build - it WILL work.
Enjoy!

This is what I've been thinking since athile was talking about it (haven't tried it yet, TBH.), but now I'm kinda confused since there's a lot being discussed about it. I've forgotten who wanted to do the weekly "what's new", but these sorts of developments would be the sort of thing that someone could really make plain once they run their course, and get the news out to everyone very plainly.

...unnngh...need more coffee...

Anyways, grats to us on the release.
Star-Demon wrote: Okay - Here goes.

sourceforge says DLL pack is for older builds, so I skipped it and updated my folder via git then simply pasted in the sourceforuge source into the folder just for double insurance.

Now - Is Cmaking this any easier?

It's not any easier.

Still searching across my whole computer for include directories and libraries to satisfy Cmake so I can get myself to Generate. Complete mess. How can I not make this a complete mess of libraries and include folders scattered all over my computer?

This time I used Audiere. After giving me trouble about other things that are already handled I skipped them and filled in the freetype, and now it's satisfied.

Image

What is SNDFILE, btw?
Nevermind, I looked at this last week - I'm missing a GCC dll of some sort and it won't install...our wiki never mentioned it. GNU compiler file, too, eh? Jeez. Another thing not even mentioned in the wiki or listed as a dependency.

Well, I got it to generate. Now I open it up the project and hit build. Let's see what happens...
. . .
Many warnings, Only error I got:

Code: Select all

6>C:\Windows\System32\OpenAL32.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2D8
So no - it failed. I probably used the wrong file, but that's the only OpenAL library after three downloads of stuff to throw at it. you guys told me that udiere would be easier. MSVC and Cmake don't care.

Can someone explain to me what was actually solved that was supposed to fix my problem with this mess?

I've been more or less just doing the same thing this whole time and grabbing all sorts of downloads - there's no order, no procedure to any of this, I've been simply been throwing random stuff at Cmake and hoping it sticks, and it feels like everyone just makes things work and there's nothing passed to anyone else on it.

I suppose I'm not tall enough to ride the ride here, since I've struggled to understand what it is I need to do to the letter and instead of having a set of clear steps to take, I'm kinda being left in the dark about what to do with only a general sense of what's wrong and how it can be fixed, which amounted to things I don't have, so I get them and they still don't work after throwing them in. Whatever it is: I don't know what to do. I'm sorry. I've been trying to get everything you wanted, trying to do what you guys say, and obviously I'm still missing all sorts of stuff and I don't know what's next anymore. I'm just doing the same thing, and what I have is a complete mess of a system and I haven't learned much.

We need to rewrite the Dev setup wiki. I can't even just go and do it myself, because it's so obvious that I haven't been able to even get to the point nail down decent instructions to get this to build. It' clear that it'll take a collective effort to really get some decent instructions down, because I'm gonna need em at this point. After weeks of grabbing, unzipping, installing, clicking folders and hitting generate, none of it has yielded a successful build.

Okay, I'm clearly too frustrated to be talking about this. Time for a break. For now, I give up on trying to build it - it's just not ready to be given a real shot yet, and there's just too many things that can go wrong right now and just not enough is actually on paper to make sense out of it.
jbo wrote: You need the OpenAL SDK and not that other installer.
amos wrote: I plan to update the wiki entry for development setup one of these days, I just need to setup a clean environment again to make sure all I catch all required steps.
best regards,
Lukasz

Locked

Who is online

Users browsing this forum: No registered users and 2 guests