It seems to me that there is another misunderstanding: to make complex things simple, they need to be discussed in detail. That’s what I’m trying to do.
To me it comes more across like someone new to the language making claims they haven’t researched in detail and then wanting people to argue with them.
There are plenty of topics on this forum explaining the details of various parts of the build system, I want you to read those first and then you can point out things that were still left unexplained, but I don’t want to re-hash things that have already been explained in other topics.
Here are some links to help you get started reading:
- I want to create a complex lib - #5 by castholm
- Best Practices for Structuring Zig Projects with External Dependencies
- Zig ways of the code reusing
- Build System Tricks
So please read some existing topics and make notes about things that don’t make sense to you and then you can link to the things you have read and found lacking in detail, describe which parts didn’t make sense to you and then we will be happy to dig into those details with you.
I think if you do this, it could be hugely valuable, because getting a fresh perspective on things is very useful, but if we have to re-hash too much it becomes an exchange that isn’t balanced and enjoyable for everyone involved.
Otherwise it seems unproductive to me to re-examine a big topic like the build system from scratch again, when there already are a lot of topics about this.
10 Likes
I think Robbie and I had a normal discussion, and Robbie had no complaints about me. If that’s not the case, let Robbie say otherwise.
We discussed very specific things, and I gave a specific example and a specific scheme for solving the problem. And I thought Robbie wouldn’t mind discussing it further.
And I am 99% sure that in the vector in which we are discussing this, no one has discussed it yet.
Based on my impressions from conversations, there is an opinion that very few people understand the build system as a complete architecture. And this means that people accept this as a dogma and don’t even try to understand the internal problems of the build system.
It seems to me that the language is at that stage of development in order to adequately address reasoned critical discussions. After all, open discussions can give rise to new views on old problems.
I’d expect something more like:
/build.zig
/build.zig.zon
/proj1/
/proj1/main.zig
zig fetch --save https://dep1+version-branch-tag
zig fetch --save https://dep2+version-branch-tag
The latter two commands would fetch the specified versions of dep1 and dep2 into /zig-pkg/ and add entries into build.zig.zon, then build.zig would need commands that define “proj1” with a source root file at /proj1/main.zig, dep1 as the module from the dep1 dependency, and dep2 as the module from the dep2 dependency, which allows /proj1/main.zig to use @import("dep1") and @import("dep2").
Once that’s defined, you could define zig build install to build the proj1 binary and zig build run to run it.
I’m interested in discussing a fully local build first. For many reasons.
Okay, as a purely local example, manually copy into /vendor/dep1 and then you’d manually add an entry to build.zig.zon using .path = /vendor/dep1 instead of using zig fetch, otherwise it’s the same.
Build condition: no paths should be changed.
It seems to me that it is very important to make a build architecture so that the user doesn’t have to adjust to the build, but the build can flexibly adjust to any user’s tasks. Golang and Rust, by the way, also had problems with this. And there were also heated discussions, which gave rise to new interesting solutions.
Curious. So you want to add the restriction that build.zig and build.zig.zon (which obviously didn’t exist before) must be in separate directories from each other?
Yes, these can be different mount points, including completely different remote devices. There may already be established strict policies within the company regarding distributed build exclusively within its own perimeter.
I don’t think that’s going to work.
Build.zig.zon is the comptime data part of a build.zig. They are two halves of a single build script.
Yep, but it’s at least very strange if all the build scenarios encounter explicit and implicit problems. And this is a reason not to be afraid to discuss it, but rather to encourage such discussions.
So it would be interesting for me to discuss this with those who consider themselves experts in the build system.
I’m going to get a little (or a lot) distracted. But I’ll be blunt as usual. Again, using a specific example.
In Golang, they broke compatibility in the latest version. And in the cryptography foundations. Moreover, no one has ever done it in my memory. The reasons for what happened can be discussed separately for a long time, but now the consequences are important. People started coming (and not just anyone, but the guys from Hashicorp), asking questions, their team didn’t have any logical answers, so it all came down to the fact that we made a decision, and shut up. But I continued to ask uncomfortable questions because I considered myself a part of the community, because Golang saved a lot of my team’s time in business projects, and I considered it important to give something in return, to help the development with the community. How did the team respond in the end? At first they started hiding my questions, and then when they got tired of it, they just banned me.
Why did they do that? First of all, because they serve the interests of a rather large corporation, for which people are goods and dust under their feet. But not only that. Behind this lies the fact that they simply don’t care about the development of the language, they only care about their salaries, bonuses, social status, etc. It’s worth taking all this away from them, and their real attitude to the language will immediately become apparent.
What am I getting at?
I believe that we have the one life, and we need to live it with dignity, without hiding our opinions and views, expressing them directly to our colleagues, criticizing any shortcomings. This is the only way to improve things, this is the only way to fix problems, this is the only way to develop.
I’ve already seen a lot of projects where people were initially forbidden to discuss certain things, and then the prohibitions became total. This is how excellent open mass projects turn into dogma-limited sects. I’ve seen this before, and therefore, if something like this is also planned here in the end, then tell me right away, and then I won’t interfere with the calm course of discussions, and I’ll only write to the issue tracker about obvious bugs.
I mean, discuss what you want but “you must split the two build files into separate directories” feels arbitrary to me. Maybe you want to build your own thing from scratch?
And, I mean, go for it. I’ll recommend learning more first and then generating build.zig code (rather than all the individual build-exe commands).
I still see the problem, as in some scenarios build.zig.zon is lost. But it’s still like a package manifest. In Golang and Rust, this is a key element of their modular systems, and users don’t even have to think about the complexity of their entire build system: users simply add a few fields to this manifest and the whole build works. And this is very important, because one team can write a project, and another team (which doesn’t have to know anything about the language at all) can build/run a project.
Immediately, users have to think constantly during build, moreover, it becomes extremely important to know the language well during build. And I think this is an important issue. But I don’t have any concrete suggestions yet. We must think, we must discuss.
It sounds like you lack self awareness. Perhaps you were being unconstructive, just as you are being in this thread, and they got tired of dealing with you.
If you want people to take you more seriously then you have to start trying to empathize more with your audience. Your posts here just make you seem clueless, both technically, and in terms of your understanding of what other people are thinking.
Have you actually used the zig build system at all? Are you making suggestions based on absolutely no first hand experience?
If the answer is “no” and “yes”, then there’s your problem. That’s an extremely anti social thing to do.
If the answer is “yes” and “no”, then you are completely failing to show and communicate that fact to the people reading your forum posts.
People here are being very patient with you and trying to help you fit in, but since you mentioned you enjoy bluntness, I’ll give it to you straight: you’re not going to be tolerated very long here either if you can’t learn how to take on a more collaborative way of engaging with people.
Sincerely, good luck
6 Likes
(post deleted by author)
not particularly relevant… but…
cargo really is not better in that regard, crates can include arbitrary files and rust also has a build.rs that can have arbitrary code.
It is not often used because cargo provides most functionality, and build.rs is very obviously an afterthought.
1 Like