Linux

[anonymous_user_99d6007e]

That it’s a good news. I switched back to Window from Linux mostly because of Unity and other game dev tools. A native UE editor for Linux will be a good opportunity for dusting my Linux partition.

[RCL (Arciel Rekman)]

@Nils;4875

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.

You should be able to build UnrealHeaderTool first, and then use it to generate headers for the other projects (“project” here corresponds to a single module, i.e. a subclass of UnrealBuildTool.ModuleRules).

Note that existing ProjectFileGenerators normally generate projects that execute UBT as their build step to do the bulk of work, and you seem to be after somewhat more ambitious goal of replacing it. I think you are better off generating CMakelists that would build through UBT as well, since you already depend on mono. I am not sure that using UBT as purely a CMakelist generator is feasible at this point.

[anonymous_user_cc82c1c2]

Thanks for pointing me at the ModuleRules, I was suspecting that I would need their information was well. I’ll try to achieve something with them next week.

[asmrpuppy]

Advocate

Just my 2 cents, I am a huge advocate of Linux.

+1 for editing capailities on Linux.

It just begs the question, what blessed IDE do think will be supported?

[RCL (Arciel Rekman)]

@Yozies;5381

Just my 2 cents, I am a huge advocate of Linux.

+1 for editing capailities on Linux.

It just begs the question, what blessed IDE do think will be supported?

Thanks

As for the IDE, I think that we will just generate CMake files, which, in turn, will be able to generate projects for a number of IDEs (note that this is not the same as Nils is apparently trying to achieve since we will still be using UBT as build system).

[Antares]

@Nils;5329

Thanks for pointing me at the ModuleRules, I was suspecting that I would need their information was well. I’ll try to achieve something with them next week.

That would be greatly appreciate ! Actually that could be a way for windows and the other to use a different IDE, like a real one…With correct intellisense… Like QtCreator =D

I don’t know why EPIC didn’t use CMAKE to generate visual project, it would be interesting for everybody to have CMAKE as BUILD solution.

[kshots]

Count me in for any linux forking, particularly with cmake. I have a bunch of little projects I’d love to use this on, and while they should all work in windows… I do all of my development in linux. The less I have to reboot, the better

[anonymous_user_ca89cd42]

@Nils;4875

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.

Hi Nils,

I also went down the road of building a custom generator, but I soon realized that the want UE4 is designed to be built is via the UnrealBuildTool only. The IDE basically acts as an editor and debugger but whenever you want to build anything is shells out to Build.sh or Build.bat to do compilation. So all compilation is done through this one command whichever IDE you use. In the end I chose to make a simple MakefileGenerator that simply greats a top level Makefile that calls a Build.sh for linux.

However, as far as I can tell if one is happy to work form the command line one doesn’t even need a generator at all, one can just run Build.sh directly. If/when you/we do need to have IDE support on linux I suggest you/we create a CMakeGenerator and works like the other generators and all ever calls Build.sh for the compilation.

My focus right now is not on IDE support but on getting all the targets to compile on linux. You can see my changes here:
https://github.com/sbc100/UnrealEngine/tree/linux

I have several of the command line targets building already. My changes are based off master rather than 4.0.

@photex at myself have been in communication on IRC and plan to work together on this? Want to join us?

Perhaps we could create wiki page representing the current state of the linux stuff and the various forks where it lives?

[anonymous_user_cc82c1c2]

I didn’t actually plan to “fork” anything, in my opinion we should rather “branch” in a sense of creating an addition to UBT instead of trying to replace it. EPIC then would have the choice to use or switch to CMake if they want to.

This way we can respect their courageous move to offer us access to their source and we can both benefit from it in the longer term.

[anonymous_user_ca89cd42]

@Nils;5592

I didn’t actually plan to “fork” anything, in my opinion we should rather “branch” in a sense of creating an addition to UBT instead of trying to replace it. EPIC then would have the choice to use or switch to CMake if they want to.

This way we can respect their courageous move to offer us access to their source and we can both benefit from it in the longer term.

Sorry, I think you misunderstood my use of the word ‘fork’. Of course the goal is to push all this stuff upstream once its ready. I was just using ‘fork’ in the github sense. i.e. we each do work in our own ‘forks’ before makes pull requests to have it upstreamed. For larger changes it can makes sense for us to push and pull from each other while working on the change.

[anonymous_user_cc82c1c2]

Ah I see, did not take github terminology into account, I’m sorry for creating confusion.

For this other point, do you also think we should not try to replace UBT and extend it instead to generate CMake files?

[anonymous_user_ca89cd42]

@Nils;5602

Ah I see, did not take github terminology into account, I’m sorry for creating confusion.

For this other point, do you also think we should not try to replace UBT and extend it instead to generate CMake files?

I think for IDE support we should build CMakeGenertor.cs which outputs CMakeLists.txt files, but that these files should not actually know anything about how to build anything (just like the xcode and vcxproj). Instead they need to know that targets should be built using Build.sh (that magic “compiler” that does all the work). It actually makes the generation process much easier since you don’t need to worry about include paths, cflags, ldflags, libpaths or macro definitions (EBT takes care of all of that instead). Unless I’ve misunderstood how things in EBT work, doing it any other way would not make sense since you’d be basically maintaining a parallel build system that could get out-of-sync with EBT.

However, I’m happy working from the command line for now, until the CMake generator is working. If you want to work on the CMakeGenerator in parallel that might make snese? You might want to start with my ‘linux’ branch, since there are lots of fixes there to make the command line EBT work there and you can concentrate on the IDE side?

[Hammerheart]

I’m also looking to contribute to Linux support although I am not likely to be very reliable right now. I am in the process of moving and starting another job but I should be able to contribute on a more regular basis in a couple months. In the meantime, I can try and contribute as I can if I can follow along on whatever channels you are using for coordination.

[anonymous_user_ca89cd42]

I made some progress last night and I can now link UE4Client and UE4Server on linux natively!

Instructions are here: https://github.com/sbc100/UnrealEngine/tree/linux/Engine/Build/BatchFiles/Linux

Running UE4Client on its own errors out in EnginePreInit right now which is probably not surprising but its a start.

I’ll try and split it up into acceptable chunks for upstreaming in the next day or too.

[RCL (Arciel Rekman)]

Wow, great job! I appreciate that you actually made a script for third party libs! Will take a look tonight.

[kshots]

That’s great news! I’ve been rather busy and probably will be for the near future (Decided UE4 was reason enough to front the $500 required for VS2013, and been hard at work learning the differences between VS2013 and VS 6 from back when I used to use it). I still want to keep linux as my primary dev environment, but after firing up UE4 in windows, I suspect there will be tools I’ll need to reboot to use for the forseeable future. I guess I’m happy enough with a linux end-product, which it appears you’re very close to reaching already.

/me groans at the prospect of going back to vcproj files rather than proper project management tools like cmake (or even autotools) :(. Oh, the things we do for the chance to use a real engine…

[anonymous_user_ca89cd42]

@kshots;7268

/me groans at the prospect of going back to vcproj files rather than proper project management tools like cmake (or even autotools) :(. Oh, the things we do for the chance to use a real engine…

Don’t worry. UE4 only uses vcxproj on the very surface. The builds themselves are all described in and performed by UnrealBuildTool (UBT). If I understand correctly, you can actually work completely from the command line, even on win32.

[RCL (Arciel Rekman)]

@sbc100;7310

If I understand correctly, you can actually work completely from the command line, even on win32.

Yes, you are correct.

[amigo]

I’ve been using Linux for decades now in one manner or another, and the only thing that really kept me from going full desktop with it was lack of certain applications.

Seeing UE4’s path towards Linux and getting a native Editor will be that tipping point for me, so I wonder what can I do to help expedite this effort?

[RCL (Arciel Rekman)]

@amigo;7572

Seeing UE4’s path towards Linux and getting a native Editor will be that tipping point for me, so I wonder what can I do to help expedite this effort?

Depends on how much time and effort you want to lend. Sorted descending:

1. Get the latest sources (sbc100’s fork is your best bet for now) and try to build/fix/otherwise improve them on your setup.
2. Contribute to documentation on wiki (which just started to appear) based on your experience with step #1.
3. Discuss/propose/otherwise show your interest either via this forum or via IRC (#UE4Linux channel on Freenode](http://webchat.freenode.net/) - if you have time for that). More “modern” means of communication (like twitter) are of course fine, too.