Compiling SSR on Windows

[joerg.mu...@gmail.com]

Hi,

we are trying to compile SSR on Windows without support for file playback. I've cloned the repository from github and checked out the c++11-branch, which supports multithreading on Windows. However, there are some issues. It comes down to two problems:

1.) Missing Libraries
So far, I've managed to get most of the needed libraries for Windows (like jack, libxml2, pthreads ...), but some are still missing:

• unistd
• eca-control-interface
• dirent
  

From what I understand is that there is no windows version of ecasound, but that is only used for file based playback so that shouldn't be a problem? Skimming through the source code it looks dirent and unistd are used for changing directories and stuff like that. So they shouldn't be necessary too?

2.) No Windows-compatible makefile
This is where I'm struggling most with. On Linux, I can just ./configure, make and "sudo make" and I'm done. But there is no autoconfigure on Windows, so what are our options here?

Thanks for any help!

[Matthias Geier]

Hi Jörg,

it's nice to see some developments towards Windows support of the SSR!

Just a few days ago, Hagen created a Wiki page for that topic:
https://github.com/SoundScapeRenderer/ssr/wiki/SSR-and-Windows

Feel free to edit this page (or add new pages), every Github user can do that!
It would be nice if you could add some information about the parts
that you were already able to get running under Windows.
Feel free to create issues and pull requests, too, if something should
be changed in the SSR sources.

On Mon, Nov 14, 2016 at 10:01 AM, <...> wrote:
>
> we are trying to compile SSR on Windows without support for file playback.
> I've cloned the repository from github and checked out the c++11-branch,
> which supports multithreading on Windows. However, there are some issues. It
> comes down to two problems:
>
> 1.) Missing Libraries
> So far, I've managed to get most of the needed libraries for Windows (like

> jack, libxml2 and pthreads), but some are still missing:

pthreads shouldn't be necessary anymore with the c++11-threads branch.

Without this branch, when compiling on Windows, you'll be limited to a
single audio thread.

> unistd

This is used in a few places ... did you try including io.h as
suggested in the following links?
http://stackoverflow.com/q/6365058
http://stackoverflow.com/q/341817

> eca-control-interface

This is part of the file playback. Simply not defining ENABLE_ECASOUND
should take care of this.

> dirent

This is only used in src/posixpathtools.h, which would have to be
ported to Windows at some point.

> From what I understand is that there is no windows version of ecasound, but
> that is only used for file based playback so that shouldn't be a problem?

Yes, just don't define ENABLE_ECASOUND in the build system.

> Skimming through the source code it looks dirent and unistd are used for
> changing directories and stuff like that. So they shouldn't be necessary
> too?

They are not only necessary for audio file playback (which you can
deactivate), but also for loading and saving audio scenes and for
loading HRIRs (for binaural playback), BRIRs (for the BRS renderer)
and pre-filters (for WFS).

> 2.) No Windows-compatible makefile
> This is where I'm struggling most with. On Linux, I can just ./configure,
> make and "sudo make" and I'm done. But there is no autoconfigure on Windows,
> so what are our options here?

TBH, I don't know. I have no experience with build systems on Windows.

I hear that cmake is popular, but I don't have experience with that either.

Probably someone else on this mailing list can give us some hints?

Good Luck,
Matthias

[Hagen Wierstorf]

Hi Jörg,

 

> 2.) No Windows-compatible makefile
> This is where I'm struggling most with. On Linux, I can just ./configure,
> make and "sudo make" and I'm done. But there is no autoconfigure on Windows,
> so what are our options here?

TBH, I don't know. I have no experience with build systems on Windows.

I hear that cmake is popular, but I don't have experience with that either.

Probably someone else on this mailing list can give us some hints?

This is indeed a tricky point. Under Windows 10 there should be an Ubuntu bash, in which you should be able to run the usual configure and make stuff. But there it can only compile and run without the GUI and I'm also not sure if you can get access to the sound card at all. In general, the better idea is most probably to switch the building system to cmake, which can be used under Windows, Linux, and Mac. The problem is that it will need some effort to translate the very hard to understand configure.ac file (https://github.com/SoundScapeRenderer/ssr/blob/master/configure.ac) to cmake and after that get it to run under Windows.

As a first start to get used to compile stuff under Windows you might have a look at this project https://github.com/TheTelephone/TheTelephone/, which uses cmake (https://github.com/TheTelephone/TheTelephone/blob/master/CMakeLists.txt) and try to get this to run with Visual Studio under Windows.

@all: Dennis told me that it can happen, that even if we get the build process running the output might be different due to the usage of a different compiler. Has anyone ever compiled the SSR with another compiler than gcc?

/Hagen 

[Sascha Michael Spors]

Dear Hagen,

> @all: Dennis told me that it can happen, that even if we get the build process running the output might be different due to the usage of a different compiler.

> Has anyone ever compiled the SSR with another compiler than > gcc?

we have compiled the SSR with clang on OS X and Linux(?)

greetings,

Sascha

[Jens Ahrens]

Yes, we (at least I) have been using clang on Mac OS X. Run "gcc --version" to see whether the terms "Apple" or "GNU" appear.

I once tried to switch my system to GNU but failed miserably.

Greets,

Jens

--
You received this message because you are subscribed to the Google Groups "SoundScape Renderer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to SoundScapeRenderer+unsub...@googlegroups.com.
To post to this group, send email to SoundScapeRenderer@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/SoundScapeRenderer/D45244AB.27537%25sascha.spors%40uni-rostock.de.

For more options, visit https://groups.google.com/d/optout.

[joerg.mu...@gmail.com]

Thanks, I will try out CMake.
I already tried Ubuntu Bash on Windows 10, but you cannot access hardware from there, so no jack, atm. There is an issue for that matter:  https://github.com/Microsoft/BashOnWindows/issues/486

[joerg.mu...@gmail.com]

Hi everybody,

I tried to get myself into CMake. I tried Matthias' tips about unistd. I also found two ports of dirent:
https://github.com/tronkko/dirent
http://www.two-sdg.demon.co.uk/curbralan/code/dirent/dirent.html

However, when building configuration.cpp, which needs posixpathtools.h, I'm getting errors like:
error C3861: 'chdir': identifier not found
error C3861: 'lstat': identifier not found
error C3861: 'fchdir': identifier not found

So I guess, the unistd.h ports are not 100% compatible. Any other ideas?

> unistd

This is used in a few places ... did you try including io.h as
suggested in the following links?
http://stackoverflow.com/q/6365058
http://stackoverflow.com/q/341817

> dirent

This is only used in src/posixpathtools.h, which would have to be
ported to Windows at some point.

Does that mean, it's impossible to build and run the SSR on Windows without a working posixpathtools.h?

[Matthias Geier]

Dear Jörg, dear Windows aficionados, dear all.

On Mon, Nov 28, 2016 at 5:12 PM, <joerg....> wrote:
>
> I tried to get myself into CMake. I tried Matthias' tips about unistd. I
> also found two ports of dirent:
> https://github.com/tronkko/dirent
> http://www.two-sdg.demon.co.uk/curbralan/code/dirent/dirent.html
>
> However, when building configuration.cpp, which needs posixpathtools.h, I'm
> getting errors like:
> error C3861: 'chdir': identifier not found
> error C3861: 'lstat': identifier not found
> error C3861: 'fchdir': identifier not found

I don't really know anything about this, but probably you should
append underscores?
https://msdn.microsoft.com/en-us/library/ms235420.aspx
The page claims that "_chdir()" is more ISO C++ conformant than
"chdir()", which doesn't really make any sense at all, but whatever.

I guess this still won't work for "_lstat()", which doesn't seem to exist.

This probably isn't the easiest way to do this. See below.

> So I guess, the unistd.h ports are not 100% compatible. Any other ideas?
>>
>> > unistd
>>
>> This is used in a few places ... did you try including io.h as
>> suggested in the following links?
>> http://stackoverflow.com/q/6365058
>> http://stackoverflow.com/q/341817
>>
>> > dirent
>>
>> This is only used in src/posixpathtools.h, which would have to be
>> ported to Windows at some point.
>
> Does that mean, it's impossible to build and run the SSR on Windows without
> a working posixpathtools.h?

Well, yes.
It would of course not be called anything with "POSIX" in it's name,
but basically posixpathtools.h has to be ported to something like
windowspathtools.h.
Or some multi-platform library can be used instead.
I would prefer not to use Boost Filesystem, because Boost is a pain to
handle in the build system and we are actually just getting rid of it:
https://github.com/SoundScapeRenderer/ssr/pull/59

I think the easiest way is just to port it using native Windows API calls.
It's actually not necessary to port the low-level POSIX calls chdir()
etc., you only need to port the high-level functions that are actually
used in the SSR code. AFAICT, these are:

make_path_relative_to_file()
make_path_relative_to_current_dir()
get_file_extension()
get_escaped_filename()

We should then probably get rid of the namespace "posixpathtools" and
replace it by something more general like "pathtools". And the
functions which are only used internally should probably be moved to a
sub-namespace (named "pathtools::internal" or something. This would be
a sign that those are not supposed to be used outside.

I just saw that the Intersense tracker code uses some
platform-dependent functions:
https://github.com/SoundScapeRenderer/ssr/blob/master/src/trackerintersense.cpp
This will have to be replaced by the "get current working directory"
and "change directory" functions from the future "pathtools".
And we probably need some kind of "get a writable temporary directory"
function ...

We can then also create a new header file "pathtools.h" which just
includes the appropriate platform-specific header based on compiler
switches.

Does that make sense at all?

cheers,
Matthias