Building Haiku_x64 from within Haiku_x64

Help
21

The instructions/steps for building Haiku are not the same thing as tracking down a source code issue. The instructions for building Haiku should always produce a working build, as long as the source code is properly written. But when bits and pieces of build instruction are changed or missing, who is to know WHAT is the cause of the problem? If you don’t have all the steps of how to make a cake, how do you know if the lousy cake is because you didn’t DO (“how to”) something… or didn’t HAVE (ingredients) something? You can’t. You’re asking me to give you a Build Log, to find out what is missing, but if the instructions for building Haiku were “set in stone” (a consensus by many devs/users that these steps are absolutely the way to get a working build), then you KNOW it’s a source code issue! And that’s another story…

I think centralizing the “Building Haiku” page and then having links to the individual “branches” of instructions, would be a good idea. There’s one, main landing page, then branches for Haiku, Ubuntu, BSD, etc. While some/many of the instructions may be duplicated, they are duplicated in one place for each “version”. The goal is to simplify/idiot-proof the build process for the less knowledgeable, not to create redundant information. Even simplify it further, so that categories of platforms are grouped together. So everything that is related to Linux (flavors of Linux), are under “Linux-related builds”, BSD would have it’s own category, same for macOS, Haiku, etc.

For Haiku x86/64, unless there were a necessary difference in instructions between 32-bit and 64-bit builds, they could all be lumped together under “Haiku x86/64”, if one set of instructions covers everything. Obviously, that doesn’t work for the different “platforms” of Haiku, like ARM, 68K, PPC, etc., which would have their own “branches”. For the obsolete, no longer functional build plaforms, like BeOS/Zeta, you just have a disclaimer stating there are no instrutions for building on those platforms anymore, as they are no longer supported at all.

For the developer-mindset (such as yourself), this may be all excess, wasted effort… but for the noob… the uninitiated… the less knowledgeable… the “Fool’s English” individual… this is a way to keep them from getting so confused/frustrated, they just walk away completely.

There are those who know only what is put before them (“Here’s a computer… there’s the power switch.”) and use it (they are “software-knowledgeable”). Those are the true “end-users”. But there are some that have just enough curiosity and desire to know “how it works”, that are the ones who want to build Haiku on a given platform. I count myself as one of those. And I want others, like me, to be able to enjoy building Haiku AND using it, not ranting and raving when something that worked a couple months or a year ago, no longer works, because something changed and the only way to fix it is to go digging all over creation and piece together the bits and pieces of (now modified) information and “figure it out” on our own.

Consider this… would we even be having this conversation, were what I propose already implemented? Aye, thar’s the rub! :smiley:

22

And there’s the problem… one person says, “Yeah, this will work.” And another person says, “Well, this part yeah, but this other part, nah.” If what was needed to build Haiku x86_64 within Haiku x86_64 was all in one place… on one page… and you didn’t have to piece together the different parts and hope you got it right… none of this would even be being discussed!

Just because developers “know” what they need, to do something, no matter where it’s located on a website… doesn’t mean it’s so obvious to everyone else who isn’t a developer. All the steps AND tools AND ingredients need to be in one place, on the counter, before you start to make the cake. Without that kind of organization… you have a messy counter and a lousy cake to show for it. And who wants that?

1 Like
23

Could you please list, in order, what steps are needed, to get Haiku x86_64 built from within Haiku x86_64. This means every URL, every file, every step, in the exact order it needs to be performed. I’m trying to avoid any more “these steps by this person, plus this step by this other person, plus…” kinda confusion. I want:

  1. Step 1
  2. Step 2
  3. Step 3…
24

I already did.
And I also told you that the steps are already consolidated in the Readme.Comiling.md.

1 Like
25

I agree that instruction for building Haiku on cleanly installed Haiku release that can be just copy pasted as is to Terminal/shell script is needed. Build instruction for other platforms (Linux/Mac OS/Windows etc.) can be more generic.

26

So complete working instruction will be:

pkgman install -y mtools cmd:python3 cmd:xorriso
git clone https://review.haiku-os.org/buildtools
git clone https://review.haiku-os.org/haiku
cd haiku
mkdir generated.x86_64
cd generated.x86_64
../configure --build-cross-tools x86_64 ../../buildtools
jam -q -j2 @nightly-anyboot

If there are no network problems and disk space is enough, it should work.

27

Our builders produce builds every night. And we watch them and make sure the build works there. Therefore, the sourcecode is fine and working. And the problem is you did not read the instructions. But no, the effort should be on us to write the same instructions in a 3rd place. Yeah sure.

Ok, let’s try the easy way for the non-knowledgeable: http://download.haiku-os.org . And I don’t see why you would build anything if you can’t follow guides/building. There is no way to idiot-proof it more. You need to know which OS you are running, what you want to build, etc. Otherwise I don’t se the point of building at all.

the instructions are different and no, we didn’t do this because it’s fun to make your life complicated.
We did this because there are different requirements. And we put the instructions on separate page, because otherwise, people mix them up.

Then do your part of the effort and read the existing instructions before complaining.

Yes, it is.

3 Likes
28

You are thinking like a developer. And getting mad, because I’m not. Let’s see here…

  1. https://www.haiku-os.org/guides/building/pre-reqs <— This page holds the part I was missing from my last attempt.
  2. https://www.haiku-os.org/guides/building/get-source-git <— This page holds the two different URL’s for the build tools and source code
  3. https://www.haiku-os.org/guides/building/compiling-x86_64 <— This page holds the compiling info.

I have to go to THREE different pages, figure out if I’m reading it right (noticing that some of the information has changed), hope I copied the right instructions (there are variations), and then hope I execute them in the right order.

Or, you could have a specific page that basically says:

To build Haiku x86_64 from within Haiku x86_64, in Terminal, do the following in this order:

  1. pkgman install -y mtools cmd:python3 cmd:xorriso
  2. git clone https://review.haiku-os.org/buildtools
  3. git clone https://review.haiku-os.org/haiku
  4. cd haiku
  5. mkdir generated.x86_64
  6. cd generated.x86_64
  7. …/configure --build-cross-tools x86_64 …/…/buildtools
  8. jam -q -j2 @nightly-anyboot

No searching for information (different links). No wondering if you read it right. No wondering if you did the steps in the right order. Just 8 simple steps, in one place, for a specific build platform.

And, now, if there is a build failure, we KNOW, it’s not because something wasn’t done right… it’s because there is a source code issue.

29

No. We would have twenty different pages like that, each with a different way to install the packages.

We need to support 11 host operating systems. We need to support building for x86 and x86_64. 11 x 2 = 22 combinations. So, what should we do? Have a list of the 22 pages and hope you pick the right one? Or split the instructions in 3 pages as we have done now?

The latter is a lot simpler for us, because when we add a new build dependency, we need to update just one of 3 pages, instead of all 22 of them. This makes our life a lot easier. Yes, there is a tradeof, which is that you must start from one page and follow 3 links. But apparently this need a degree in software engineering?

Ok then, as I mentionned 3 times, we have the single page version of this in ReadMe.compiling.md. And again, the instructions you used in your first post are not from one of our pages. So, I’m annoyed because you did not even try to read the existing documentation. Why would better/simpler docs help then? You don’t read them anyway!

1 Like
30

Please remember: you can always propose changes for the documentation here:

2 Likes
31

Yes, we generally expect that those who read developer documentation and try to compile the OS are, in fact, developers; and we provide pre-build images and packages for people who are not. But plenty of non-developers have used the guides to compile Haiku too, but the are not the primary audience for them, indeed.

32

Ok, forgive me… but I just read this link:

And I’m just as confused as I was before… if not MORESO. Maybe I’m just “Developer-mentally Disabled” or something. Yeah… that’s it. :smiley:

33

Not really. 2 pages is enough. One for Haiku, and another for another OSes. My instruction is also applicable to other architectures, x86_64 should be replaced with arm, arm64, sparc etc. and build target may be need to adjusted: @minimum-mmc for ARM etc… 32 bit Haiku need special threatment because gcc2 and gcc4+ hybrid build is required. 32 bit Haiku also can be built without build tools (and it will be nice also for x86_64 but currently it don’t build without build tools).

Instruction for building 32 bit Haiku on 32 bit Haiku:

pkgman install -y mtools cmd:python3 cmd:xorriso
git clone https://review.haiku-os.org/haiku
cd haiku
mkdir generated.x86gcc2
cd generated.x86gcc2
../configure --target-arch x86 --target-arch x86_gcc2
jam -q -j2 @nightly-anyboot

Git access can be reconfigured after clone, so only anonymous access is enougth for basic instruction. People who has commit access propably already knows how to do it.

1 Like
35

Ty shallow clone:

git clone --depth 1 https://review.haiku-os.org/buildtools.git
37

Please make your homework and research what shallow clone means to get answer to your question and/or do the cloning in Windows if you wish.

38

If you want a page with no “if” anywhere, you end up with different page for each Linux distro, and for each target arch. Because yes, pretty much each step needs to be adjusted to what you’re doing. This is why we have split the guide in 3 parts: one to install the dependencies (depends on the host OS), one to get the sourcecode (always the same), one to configure and build (depends mainly on the target, and in some special cases on the host).

So yes, in the end the instructions are not very complex for each combination. But there are a lot of combinations and this would be very repetitive. And I’m sure we would get complaints because people would still manage to copypaste the wrong block anyway.

39

Well, it worked! Thank you one and all for your help. Greatly appreciated.screenshot1

1 Like
40

Following this discussion here prompted me to try and compile Haiku myself, which I’ve never done before. Of course I have some knowledge about Haiku and also about compiling software, and I’m also a developer (whatever relevance this has to the current topic). So I went straight along the instructions in the documentation at https://www.haiku-os.org/guides/building . I compiled Haiku x86_64 under 64bit Ubuntu 18.04. Everything was very straightforward and worked without any problems. In my opinion the building process is very well documented and I really don’t see any need for improvement here. (It is very rare for me to say something like that :slight_smile: ) Especially if we keep in mind that we’re talking about an entire operating system here. I’ve compiled many applications that were much harder to compile and much less documented.
Anyway, just my opinion.

6 Likes
41

We could put the buildtools as submodule into the haiku tree, jam scripts could be adjusted, so if the user request a 64 bit build on 64 bit, it would automatically check out the buildtools submodule and using that.
We can ofc. check for the host variable, if it isn’t Haiku, the build scripts could try the best to set everything up accordingly.
This would mean extra complexity in the buildscripts, probably we don’t want that because maintenance.

@Luposian: now that you got it working would you reread the official build guides and propose changes to make it easier for beginners?

42

This isn’t even accounting for cross compiling, which would add at least 11 more pages, and it’s not accounting for building for or on nonbooting devices for development.

The problem is, you’re blaming your mistake of “not following directions” on the documentation. If the single file of build instructions for it confused you more, then three pages sounds reasonable when compared to one. Your suggestion does have its merrits, however, I view “dummifying” the building of software to be the job of the community. There are guides for how to build your own linux kernel, and software around it. If you want to see the closest comparison to haiku’s build guide in linux, though? Look at: building linux from scratch. You’re building everything, and each thing has a chapter with 3+ pages. That’s no where near as simple as building Haiku, no where near as safe as haiku, (you could brick your main install, if you’re building from an installed system,) and only doable on linux.