Linux

General Feedback & Requests
1

Hello,

Is there any possibility to add support for Linux? I don’t think that is is impossible and for Independent developer is Linux platform very important. If you can also add Editor support for linux it will be very great!

Thanks,
.

2

I would TOTALLY be willing to pay 30 a month if you had a Linux version of UDK4.
Winblows just meh.

3

Getting a strange feeling of deja-vu.

4

I’m hope Linux Support become real.

5

If you check out the source in GitHub you can see the beginnings of Linux support in there and we have the engine up and running on SteamBox. We have folks working on this :slight_smile:

I got my start at Epic working on the Linux version of Unreal Tournament via the OpenUT community project and my hope is that seasoned Linux developers will help us accelerate the state of the port.

6

That’s very cool information! I hadn’t much time to explore sources!

What about Linux Editor?

We have sources so yea, there is possibility to build it. But official support is way better :slight_smile:

7

We are talking to some external partners about getting help with some of the dependencies for that, but overall it is on the bottom of the priority stack as we want to make sure we have the basics rights before going to the next phase.

Our priority stack on Linux is as follows:

  1. Linux dedicated server
  2. SteamBox
  3. general Linux client
  4. Linux editor

The dedicated server is pretty stable nowadays as it is what we use to host our internal games.

SteamBox support is a variant of general Linux client support and our focus there as it’s less of a compatibility hassle. Hopefully the community can chime in as well and help us out with both testing and development.

General Linux client support is going to take some time as there are a lot of moving pieces, but luckily in my experience Linux users are generally tech savvy hackers, tinkerers, and developers, and I hope we will see a decent number of pull requests on GitHub to fix little niggly stuff.

Linux Editor is a larger task. We have the Editor up and running on Mac OS X, which means a lot of ground work has been laid to support it, but it is a lot of code and a lot of surface area. This is an area we tend to engage third parties to help accelerate.

8

Great information! Thank you!

9

That’s great to hear, I’ve booted up windows for the first time in a long while to try the engine out but I’m missing linux already!

Will there be any form of issue tracker specific to porting to linux? On such a large project I imagine it takes quite intimate knowledge of how things work to even begin thinking of helping port it. Perhaps if you give some general guidance on what to focus on, you could expedite the communities efforts to help! :smiley:

10

I’ve subscribed with the sole purpose of helping to make native Linux development (including the editor) a reality. :slight_smile: Is there a fork that serves as the primary touch-stone for the Linux effort?

11

@photex: The bulk of Linux development happens internally, community forks are yet to appear.

12

With regard to coordination – that is something close to my heart and we’re looking for ways to make us more transparent as a company and allow tighter collaboration on code efforts with folks not inside our four walls. This is not going to happen overnight, but it is something I care deeply about.

13

Thanks guys. Keep me/us posted once there is a rallying point. :slight_smile: I’m really looking forward to it.

14

I am also very interesting in moving the Linux support forward. I think it would be useful for us coordinate in a somebody’s private fork where we can work together to build something that Epic might eventually accept upstream. A forum category for Linux might be useful too in order to coordinate efforts. I’m a little concerned about duplicating the efforts of internal Epic folks, but hopefully they will be pushing updates to github frequently enough that we can mostly avoid this.

This first task seems to be to get the project generator running on linux and add files to the Engine/Build folder. Has anyone started this already who would like to share? Anyone at Epic already have this working? Perhaps these files could be included in the next public push?

cheers,
sam

15

Right now Linux targets are cross-compiled, since this is easier logistically, but support for compilation on the Linux machine itself is coming too - meanwhile we’re going to provide a Linux cross-toolchain, or at least ct-ng files so you guys could build your own one. The Linux roadmap is roughly like that:

  1. Add missing bits required for cross-compilation of Linux client (note that it doesn’t mean editor, just game projects).
  2. Add ability to compile the above targets on the Linux machine itself.
  3. Add ability to cook (i.e. prepare builds) on the Linux machine.
  4. And finally, port over the tools, including the editor.

I think this makes the most sense for everyone, but if you think our priorities are wrong, feel free to beat us to that, particularly to #2 and #4 :slight_smile:

As for setting up private forks - feel free to set up your own one and drive this! I may also expose stuff in my fork earlier than in the master branch, we shall see…

16

I’m all game for #2. Cross-compiling isn’t ideal for me (I don’t own windows heh).

Avoiding a Mono requirement for builds would be nice. Mono and Linux are not as tight as they once were in my opinion and there is a wide variety of build systems for native development that could be suitable on every platform. Gyp, Waf, CMake, premake all spring to mind. I think each of those can build visual studio and xcode projects as well. As a member of the church of Emacs I am in favor of something that generates Makefiles. In particular going with CMake would make it possible to easily use QtCreator which is a very fine tool for C++ development.
With a good build in-place it could be very nice for anyone also interested in working under Windows using MingW as well. Even if I decided to buy Windows, paying for Visual Studio isn’t on my todo list.

With #2 done I’m most interested in starting down the path for #4 :slight_smile:

@sbc100 let’s make a fork and start hacking! :slight_smile: Are you on freenode? My handle is photex. I’m always online (I run ZNC) but not always at a computer but it’s probably the best way for us to start coordinating. Let’s pick a channel there perhaps.

17

I too am personally interested in pushing ahead with #2.

RCL_, I think it would be great to combine efforts and share work early to avoid duplication. Please let is know if/when you have a private fork setup that we can subscribe. I already have mine setup at https://github.com/sbc100/UnrealEngine.

photex, I’m on freenode sometimes as sbc100. Feel free to get in touch there. Regarding mono I don’t think its worth doing away with it. Better to keep in line with what Epic use. I’ve already manged to build and run the project generator on Ubuntu/Precise. I imagine it has a Makefile-generating backend for the html5 engine? … but I haven’t poked around too much in there yet. Certainly, generating Makefiles or CMakeLists.txt would make sense to me.

18

You may find some of my changes to compile on case-sensitive filesystems useful: https://github.com/EpicGames/UnrealEngine/pull/11

19

Thanks guys.

@photex: as for switching to another build system and/or removing mono requirement - maintaining two build systems is hard (as the less used one will be getting out of sync all the time), and at least for the moment being we are definitely more comfortable using UBT (especially considering its tight coupling with UAT) than anything else. So, don’t hold your breath… :slight_smile:

@xylor - thanks for your case-sensitive changes, we’re picking them up - although not exactly as given, please see the followup on your pull request.

@sbc100 - will do.

20

I was trying to create a CMakeProjectFilesGenerator for UBT last weekend, and at least managed to generate some CMake files. However, I’m now stuck, because I don’t know about the dependencies between the different project files that are to be generated.

I guess that UnrealHeaderTool has to be compiled for the UE4 project to work, because there are references to *.generated.h headers. However, the UnrealHeaderTool needs parts of the Core (Runtime/Core/Private/HAL/OutputDevices.cpp), which in turn is part of the UE4 project, so there seems to be a cyclic dependency.

As UBT works for other ProjectFileGenerators, it can’t be a general problem, could you please give me a hint on what I’m not seeing? I can share my existing code next week, if somebody is interested.