Support only ninja built from source


(Wojciech Czekalski) #1

This is a humble proposal (or rather thought) to drop support for ninja which does not come from source.

This is motivated by two things:
1. I just wasted an hour figuring out what’s wrong, and applying workarounds
2. I *think* (please correct me if I’m wrong), there are no disadvantages of removing it, it will just simplify implementation of scripts.

I ran into it running `build-toolchain` script and it couldn’t find ninja. It came out that `build-toolchain` uses a preset which makes `build-script` actually build ninja.

Since it is not realistically possible to document everything in a big project like this, I think that gradually removing complexity (even if it is marginal) is a good thing.

Are there any disadvantages? What do you think?


(Joe Groff) #2

This particular issue is documented in the readme:

https://github.com/apple/swift/blob/master/README.md#ninja

If you check out Ninja as described next to your other checkouts, build-script will build and use it for you. Ninja is significantly faster than other build options, so we're not going to drop support for it. It sounds like we might need better failovers when Ninja isn't available, though.

-Joe

···

On Mar 14, 2016, at 2:21 AM, Wojciech Czekalski via swift-dev <swift-dev@swift.org> wrote:

This is a humble proposal (or rather thought) to drop support for ninja which does not come from source.

This is motivated by two things:
1. I just wasted an hour figuring out what’s wrong, and applying workarounds
2. I *think* (please correct me if I’m wrong), there are no disadvantages of removing it, it will just simplify implementation of scripts.

I ran into it running `build-toolchain` script and it couldn’t find ninja. It came out that `build-toolchain` uses a preset which makes `build-script` actually build ninja.

Since it is not realistically possible to document everything in a big project like this, I think that gradually removing complexity (even if it is marginal) is a good thing.


(Ben Langmuir) #3

This is a humble proposal (or rather thought) to drop support for ninja which does not come from source.

This is motivated by two things:
1. I just wasted an hour figuring out what’s wrong, and applying workarounds
2. I *think* (please correct me if I’m wrong), there are no disadvantages of removing it, it will just simplify implementation of scripts.

I ran into it running `build-toolchain` script and it couldn’t find ninja. It came out that `build-toolchain` uses a preset which makes `build-script` actually build ninja.

I’m not sure I understand what the issue was. Were you missing the ninja source, but the script expected it? If so, we should improve the error handling in the script to tell you what the problem is.

Since it is not realistically possible to document everything in a big project like this, I think that gradually removing complexity (even if it is marginal) is a good thing.

Are there any disadvantages? What do you think?

Strong -1 from me. This would make it much less convenient to run `ninja` directly from the build directory, which is how I do all my incremental builds.

···

On Mar 14, 2016, at 2:21 AM, Wojciech Czekalski via swift-dev <swift-dev@swift.org> wrote:

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Dmitri Gribenko) #4

Hi Wojciech,

I'm afraid there are significant disadvantages, I can think of two:

1. Some developers use llbuild as a ninja replacement to test llbuild.

2. It is very inconvenient to invoke ninja from the build directory, e.g.:

build/swift-macosx-x86_64$ ../ninja-build/ninja check-swift

Dmitri

···

On Mon, Mar 14, 2016 at 2:21 AM, Wojciech Czekalski via swift-dev <swift-dev@swift.org> wrote:

This is a humble proposal (or rather thought) to drop support for ninja which does not come from source.

This is motivated by two things:
1. I just wasted an hour figuring out what’s wrong, and applying workarounds
2. I *think* (please correct me if I’m wrong), there are no disadvantages of removing it, it will just simplify implementation of scripts.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Wojciech Czekalski) #5

My statement of the problem was unfortunate.

Anyway, the script I used was not what I should’ve used to solve a problem I had. The preset in the script is probably the right thing. Sorry for raising this. If a similar issue appears in the future and is a real issue I will submit a PR to a script rather than proposing such „simplifications”.

Thanks for amazing and quick response as always!
Swift team is :100:

···

Dnia 14.03.2016 o godz. 17:49 Ben Langmuir <blangmuir@apple.com> napisał(a):

On Mar 14, 2016, at 2:21 AM, qWojciech Czekalski via swift-dev <swift-dev@swift.org> wrote:

This is a humble proposal (or rather thought) to drop support for ninja which does not come from source.

This is motivated by two things:
1. I just wasted an hour figuring out what’s wrong, and applying workarounds
2. I *think* (please correct me if I’m wrong), there are no disadvantages of removing it, it will just simplify implementation of scripts.

I ran into it running `build-toolchain` script and it couldn’t find ninja. It came out that `build-toolchain` uses a preset which makes `build-script` actually build ninja.

I’m not sure I understand what the issue was. Were you missing the ninja source, but the script expected it? If so, we should improve the error handling in the script to tell you what the problem is.

Since it is not realistically possible to document everything in a big project like this, I think that gradually removing complexity (even if it is marginal) is a good thing.

Are there any disadvantages? What do you think?

Strong -1 from me. This would make it much less convenient to run `ninja` directly from the build directory, which is how I do all my incremental builds.

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev