OpenXcom Forum

Modding => OpenXcom Extended => OXCE Builds & Ports => Topic started by: Stoddard on June 08, 2018, 10:49:05 pm

Title: [Info] Linux build farm
Post by: Stoddard on June 08, 2018, 10:49:05 pm
My buildfarm currently builds Debian jessie64, Ubuntu trusty32, trusty64 and xenial64 (that's 2014 and 2016 LTS releases).

It's time to blow up this farm and build a new one.

Any opinions on which distros/releases it should build for?

Xenial, which is 16.04 x64 stays, as does jessie64. Ubuntu bionic (18.04) x64 will join them in any case, and trusty gets dropped unless someone relies on it.

Anything else?
Title: Re: Linux builds
Post by: R1dO on June 09, 2018, 12:23:14 am
Just as food for thought.

Instead of creating builds for targeted distros. Why not build appimages/snaps (like knapsu did).

Unless you are setting up those builds so that distros can easily put them in their package manager ... in that case ... disregard this ;)
Title: Re: Linux builds
Post by: Stoddard on June 09, 2018, 12:32:59 am
Just as food for thought.

Instead of creating builds for targeted distros. Why not build appimages/snaps (like knapsu did).

Unless you are setting up those builds so that distros can easily put them in their package manager ... in that case ... disregard this ;)

No problem. The farm doesn't care as long as there are instructions on how to farm.

Any other suggestions?

PS. As of right now trusty(14.04) builds won't be built.

EDIT

I looked into Appimage/Snaps and I kind of don't understand why should I even bother. It's either I build N builds for N distros, or I build M builds for N distros (M<N), but then have to test M builds on N distros, which is so much more work, that it's much easier to just build N builds and be done with it.


Title: Re: Linux builds
Post by: R1dO on June 09, 2018, 07:05:30 pm
Not that i am really knowledgeable about those.

But according to my understanding the strong point of this technology (including flatpacks, i forgot to mention them) is that the images are kinda independent from the distro.
From a user perspective they can be confident that they can just download the binary and know it will run without them having to know which distro they are on.

You do have a point with testing though.
Title: Re: Linux builds
Post by: Stoddard on June 12, 2018, 06:35:31 pm
But according to my understanding the strong point of this technology (including flatpacks, i forgot to mention them) is that the images are kinda independent from the distro.

Yes, but the drawback is that one has to somehow draw the line on which libraries get packaged. This leads either to choosing a lowest-common-denominator and missing features/performance fixes, or put in latest libraries but then face bugs when something those rely on isn't supported (like, one brings his own OpenGL stack, and it just blows up on an old kernel)


Ubuntu 18.04/bionic builds are up. Latest yaml-cpp is linked in, it might improve mod/savegame loading times.

edit: the new yaml-cpp feels snappier than the 0.5.3. xenial builds upgraded.
Title: Re: Linux builds
Post by: Stoddard on June 23, 2018, 03:04:14 am
SoldierTransformations don't compile:

Code: [Select]
/home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.cpp: In member function ‘void OpenXcom::SoldierTransformationState::performTransformation()’:
/home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.cpp:339:160: error: no matching function for call to ‘find(std::vector<OpenXcom::Soldier*>::iterator, std::vector<OpenXcom::Soldier*>::iterator, OpenXcom::Soldier*&)’
    std::vector<Soldier*>::iterator it = find(_game->getSavedGame()->getDeadSoldiers()->begin(), _game->getSavedGame()->getDeadSoldiers()->end(), _sourceSoldier);
                                                                                                                                                                ^
In file included from /usr/include/c++/7/bits/locale_facets.h:48:0,
                 from /usr/include/c++/7/bits/basic_ios.h:37,
                 from /usr/include/c++/7/ios:44,
                 from /usr/include/c++/7/istream:38,
                 from /usr/include/c++/7/sstream:38,
                 from /home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.cpp:20:
/usr/include/c++/7/bits/streambuf_iterator.h:369:5: note: candidate: template<class _CharT2> typename __gnu_cxx::__enable_if<std::__is_char<_CharT2>::__value, std::istreambuf_iterator<_CharT> >::__type std::find(std::istreambuf_iterator<_CharT>, std::istreambuf_iterator<_CharT>, const _CharT2&)
     find(istreambuf_iterator<_CharT> __first,
     ^~~~
/usr/include/c++/7/bits/streambuf_iterator.h:369:5: note:   template argument deduction/substitution failed:
/home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.cpp:339:160: note:   ‘__gnu_cxx::__normal_iterator<OpenXcom::Soldier**, std::vector<OpenXcom::Soldier*> >’ is not derived from ‘std::istreambuf_iterator<_CharT>’
    std::vector<Soldier*>::iterator it = find(_game->getSavedGame()->getDeadSoldiers()->begin(), _game->getSavedGame()->getDeadSoldiers()->end(), _sourceSoldier);
                                                                                                                                                                ^
/home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.cpp: In member function ‘void OpenXcom::SoldierTransformationState::btnLeftArrowClick(OpenXcom::Action*)’:
/home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.cpp:364:132: error: no matching function for call to ‘find(std::vector<OpenXcom::Soldier*>::iterator, std::vector<OpenXcom::Soldier*>::iterator, OpenXcom::Soldier*&)’
  std::vector<Soldier*>::const_iterator iter = find(_filteredListOfSoldiers->begin(), _filteredListOfSoldiers->end(), _sourceSoldier);
                                                                                                                                    ^
In file included from /usr/include/c++/7/bits/locale_facets.h:48:0,
                 from /usr/include/c++/7/bits/basic_ios.h:37,
                 from /usr/include/c++/7/ios:44,
                 from /usr/include/c++/7/istream:38,
                 from /usr/include/c++/7/sstream:38,
                 from /home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.cpp:20:
/usr/include/c++/7/bits/streambuf_iterator.h:369:5: note: candidate: template<class _CharT2> typename __gnu_cxx::__enable_if<std::__is_char<_CharT2>::__value, std::istreambuf_iterator<_CharT> >::__type std::find(std::istreambuf_iterator<_CharT>, std::istreambuf_iterator<_CharT>, const _CharT2&)
     find(istreambuf_iterator<_CharT> __first,
     ^~~~
/usr/include/c++/7/bits/streambuf_iterator.h:369:5: note:   template argument deduction/substitution failed:
/home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.cpp:364:132: note:   ‘__gnu_cxx::__normal_iterator<OpenXcom::Soldier**, std::vector<OpenXcom::Soldier*> >’ is not derived from ‘std::istreambuf_iterator<_CharT>’
  std::vector<Soldier*>::const_iterator iter = find(_filteredListOfSoldiers->begin(), _filteredListOfSoldiers->end(), _sourceSoldier);
                                                                                                                                    ^
/home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.cpp: In member function ‘void OpenXcom::SoldierTransformationState::btnRightArrowClick(OpenXcom::Action*)’:
/home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.cpp:381:132: error: no matching function for call to ‘find(std::vector<OpenXcom::Soldier*>::iterator, std::vector<OpenXcom::Soldier*>::iterator, OpenXcom::Soldier*&)’
  std::vector<Soldier*>::const_iterator iter = find(_filteredListOfSoldiers->begin(), _filteredListOfSoldiers->end(), _sourceSoldier);
                                                                                                                                    ^
In file included from /usr/include/c++/7/bits/locale_facets.h:48:0,
                 from /usr/include/c++/7/bits/basic_ios.h:37,
                 from /usr/include/c++/7/ios:44,
                 from /usr/include/c++/7/istream:38,
                 from /usr/include/c++/7/sstream:38,
                 from /home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.cpp:20:
/usr/include/c++/7/bits/streambuf_iterator.h:369:5: note: candidate: template<class _CharT2> typename __gnu_cxx::__enable_if<std::__is_char<_CharT2>::__value, std::istreambuf_iterator<_CharT> >::__type std::find(std::istreambuf_iterator<_CharT>, std::istreambuf_iterator<_CharT>, const _CharT2&)
     find(istreambuf_iterator<_CharT> __first,
     ^~~~
/usr/include/c++/7/bits/streambuf_iterator.h:369:5: note:   template argument deduction/substitution failed:
/home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.cpp:381:132: note:   ‘__gnu_cxx::__normal_iterator<OpenXcom::Soldier**, std::vector<OpenXcom::Soldier*> >’ is not derived from ‘std::istreambuf_iterator<_CharT>’
  std::vector<Soldier*>::const_iterator iter = find(_filteredListOfSoldiers->begin(), _filteredListOfSoldiers->end(), _sourceSoldier);
                                                                                                                                    ^


I'm not quite capable to decipher this vomit right now, will appreciate any help.

Code: [Select]
$ gcc --version
gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0


EDIT:

Even better, after adding an #include <algorithm>:
Code: [Select]
In file included from /usr/include/c++/7/bits/stl_algobase.h:71:0,
                 from /usr/include/c++/7/vector:60,
                 from /home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/../Engine/State.h:20,
                 from /home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.h:20,
                 from /home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.cpp:19:
/usr/include/c++/7/bits/predefined_ops.h: In instantiation of ‘bool __gnu_cxx::__ops::_Iter_equals_val<_Value>::operator()(_Iterator) [with _Iterator = __gnu_cxx::__normal_iterator<OpenXcom::Soldier**, std::vector<OpenXcom::Soldier*> >; _Value = const OpenXcom::Soldier]’:
/usr/include/c++/7/bits/stl_algo.h:120:14:   required from ‘_RandomAccessIterator std::__find_if(_RandomAccessIterator, _RandomAccessIterator, _Predicate, std::random_access_iterator_tag) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<OpenXcom::Soldier**, std::vector<OpenXcom::Soldier*> >; _Predicate = __gnu_cxx::__ops::_Iter_equals_val<const OpenXcom::Soldier>]’
/usr/include/c++/7/bits/stl_algo.h:161:23:   required from ‘_Iterator std::__find_if(_Iterator, _Iterator, _Predicate) [with _Iterator = __gnu_cxx::__normal_iterator<OpenXcom::Soldier**, std::vector<OpenXcom::Soldier*> >; _Predicate = __gnu_cxx::__ops::_Iter_equals_val<const OpenXcom::Soldier>]’
/usr/include/c++/7/bits/stl_algo.h:3907:28:   required from ‘_IIter std::find(_IIter, _IIter, const _Tp&) [with _IIter = __gnu_cxx::__normal_iterator<OpenXcom::Soldier**, std::vector<OpenXcom::Soldier*> >; _Tp = OpenXcom::Soldier]’
/home/lxnt/projects/MerCOM/16B/OpenXcom/src/Basescape/SoldierTransformationState.cpp:366:133:   required from here
/usr/include/c++/7/bits/predefined_ops.h:241:17: error: no match for ‘operator==’ (operand types are ‘OpenXcom::Soldier*’ and ‘const OpenXcom::Soldier’)
  { return *__it == _M_value; }
           ~~~~~~^~~~~~~~~~~

I'm at a loss for words.

EDIT2:

Okay, that was my fault.

But if anyone ever complains about how Rust craps out at every imagined opportunity to compared to... well, I'll tell'em to just go back to their BASIC.


@Meridian, please merge

Code: [Select]
--- a/src/Basescape/SoldierTransformationState.cpp
+++ b/src/Basescape/SoldierTransformationState.cpp
@@ -37,6 +37,7 @@
 #include "../Savegame/SavedGame.h"
 #include "../Savegame/Soldier.h"
 #include "../Savegame/Transfer.h"
+#include <algorithm>
 
 namespace OpenXcom
 {

or it just doesn't build on recent compilers.
Title: Re: Linux builds
Post by: ohartenstein23 on June 23, 2018, 03:33:21 am
It compiled fine for Meridian and I, but if adding the include fixes compiling for you, then maybe it should be added.
Title: Re: Linux builds
Post by: Stoddard on June 23, 2018, 03:37:41 am
It compiled fine for Meridian and I, but if adding the include fixes compiling for you, then maybe it should be added.

Crapped out for me on newer compilers, including Ubuntu 16.04; older stuff like gcc 5.4 (I think) for the win32/64 builds still worked.

I guess another bit of progress in C++ standards, eeewww
Title: Re: Linux builds
Post by: ohartenstein23 on June 23, 2018, 03:47:21 am
Huh, Ubuntu 16.04 is what I use regularly, never got this issue.
Title: Re: Linux builds
Post by: Stoddard on June 23, 2018, 04:13:51 am
Huh, Ubuntu 16.04 is what I use regularly, never got this issue.

Might be the break is between 5.3 and 5.4 then.

5.3 from MXE, 4.9.2 for jessie built it just fine
but 5.4+ and clang choked
Title: Re: Linux builds
Post by: ohartenstein23 on June 23, 2018, 05:42:29 am
Maybe the issue is clang?  My gcc is version 5.4, but I compile just via
Code: [Select]
make -f Makefile.simple in the src folder.
Title: Re: Linux builds
Post by: Yankes on June 23, 2018, 01:30:51 pm
Issue is what headers are included by other std headers. Simply one compiler could load more for internal usage and another do not. Then when you rally on this behavior instead of including header explicitly you get error like this on other compilers.
Title: Re: Linux builds
Post by: Meridian on June 23, 2018, 01:47:28 pm
@Meridian, please merge

Code: [Select]
--- a/src/Basescape/SoldierTransformationState.cpp
+++ b/src/Basescape/SoldierTransformationState.cpp
@@ -37,6 +37,7 @@
 #include "../Savegame/SavedGame.h"
 #include "../Savegame/Soldier.h"
 #include "../Savegame/Transfer.h"
+#include <algorithm>
 
 namespace OpenXcom
 {

or it just doesn't build on recent compilers.

will do
Title: Re: Linux builds
Post by: tkzv on July 15, 2018, 01:35:25 am
Can't download from https://lxnt.wtf/oxem/#/ExtendedPlus again.
"Oh snap! Error 0 occurred, and it means “Server is out of reach”."
Title: Re: Linux builds
Post by: Stoddard on July 15, 2018, 12:32:20 pm
Can't download from https://lxnt.wtf/oxem/#/ExtendedPlus again.
"Oh snap! Error 0 occurred, and it means “Server is out of reach”."

Hmm. For some reason the javascript on the page failed to fetch the directory index.

Did you try to force-reload the whole page? Does it work now?

Title: Re: [Info] Linux build farm
Post by: Stoddard on November 05, 2018, 01:32:25 am
Status update.

The site (lxnt.wtf) and the buildfarm has been finally moved to a new server.

Currently building for Ubuntu Bionic, Ubuntu Xenial, Debian Stretch, Android, Win32 and Win64.

And I finally fixed this crap with site going offline at random times. Or so I hope.

Anyone wanting builds for some other system please contact me.


Title: Re: [Info] Linux build farm
Post by: wolfreal on November 05, 2018, 03:13:09 am
Arch :)
Title: Re: [Info] Linux build farm
Post by: Stoddard on November 05, 2018, 10:09:42 am
Arch :)

Those are binaries, not packages. Are there any problems running ubuntu/debian binaries on arch?
Title: Re: [Info] Linux build farm
Post by: wolfreal on November 06, 2018, 08:28:19 am
Normally, no. I was just dreaming about having an AUR package.  :P

The only thing that can get annoying are dependencies. But nothing serious 
Title: Re: [Info] Linux build farm
Post by: Stoddard on November 06, 2018, 02:43:13 pm
Normally, no. I was just dreaming about having an AUR package.  :P

Well, I don't know anything about Arch or how to make AUR packages, never used it.

I don't do Debian/Ubuntu packages because I'm not sure if they'd work ok, and have no time to test :-/ . No problem setting up a PPA/repo, but nothing to fill it up with.

I don't do AppImages/etc because IMO it's too much work to ensure they don't accidentally pull a "system" library and break on upgrade, like it happened with libXext to someone recently (f28-f29 upgrade iirc).

The border between app and system libs is too ambigous on Linux. And I also have zero idea how such an image is supposed to find the resources/mods and no time to investigate to be able to test it.

Suggestions on anything are welcome.