I recently had some discussions about how to share those little tips and tricks which everyone has to make building, debugging, etc. the swift compiler easier.
And actually we already have a central place for this: it’s the docs folder in the swift repo. Especially the DebuggingTheCompiler.rst document contains many useful little things which might help debugging the compiler.
So with this email I want to “announce” this, because I found that many people didn’t know that.
And also I’d like to encourage everyone to contribute to DebuggingTheCompiler.rst and other documents.
Another thing is that many people have implemented their own little helper scripts for various purposes, which they share by email with others and those emails get lost, and nobody knows what’s the latest version of a script, etc.
We have many of such scripts already in utils. But utils got already very convoluted. So I propose to create a sub-folder, e.g. ‘dev-scripts’ to place such scripts (just for new scripts, I’m not proposing moving existing scripts). The intention is to keep the bar low to contribute to dev-scripts. So scripts may be not super-polished and it’s also ok to have multiple scripts which do similar things.
Some scripts might get attention and turn out to be useful for many people and thus get improved over time. We can eventually move such scripts out of dev-scripts into the “production” folder utils.
I always dislike wrapper scripts because it means that people are working around undesirable behavior in a tool rather than fixing it. But that doesn't seem to be a practical answer, because people are already using wrapper scripts. (I've lost this argument several times before.)
Jordan
···
On Oct 17, 2017, at 17:25, Erik Eckstein via swift-dev <swift-dev@swift.org> wrote:
I recently had some discussions about how to share those little tips and tricks which everyone has to make building, debugging, etc. the swift compiler easier.
And actually we already have a central place for this: it’s the docs folder in the swift repo. Especially the DebuggingTheCompiler.rst document contains many useful little things which might help debugging the compiler.
So with this email I want to “announce” this, because I found that many people didn’t know that.
And also I’d like to encourage everyone to contribute to DebuggingTheCompiler.rst and other documents.
Another thing is that many people have implemented their own little helper scripts for various purposes, which they share by email with others and those emails get lost, and nobody knows what’s the latest version of a script, etc.
We have many of such scripts already in utils. But utils got already very convoluted. So I propose to create a sub-folder, e.g. ‘dev-scripts’ to place such scripts (just for new scripts, I’m not proposing moving existing scripts). The intention is to keep the bar low to contribute to dev-scripts. So scripts may be not super-polished and it’s also ok to have multiple scripts which do similar things.
Some scripts might get attention and turn out to be useful for many people and thus get improved over time. We can eventually move such scripts out of dev-scripts into the “production” folder utils.
Any scripts should be subject to the same code review and design policies as the rest of the compiler. A bisection script or build-script seem fine, but a four line script to automate something is probably not the right thing to include.
-Chris
···
On Oct 17, 2017, at 6:05 PM, Jordan Rose via swift-dev <swift-dev@swift.org> wrote:
I always dislike wrapper scripts because it means that people are working around undesirable behavior in a tool rather than fixing it. But that doesn't seem to be a practical answer, because people are already using wrapper scripts. (I've lost this argument several times before.)
Jordan
On Oct 17, 2017, at 17:25, Erik Eckstein via swift-dev <swift-dev@swift.org> wrote:
I recently had some discussions about how to share those little tips and tricks which everyone has to make building, debugging, etc. the swift compiler easier.
And actually we already have a central place for this: it’s the docs folder in the swift repo. Especially the DebuggingTheCompiler.rst document contains many useful little things which might help debugging the compiler.
So with this email I want to “announce” this, because I found that many people didn’t know that.
And also I’d like to encourage everyone to contribute to DebuggingTheCompiler.rst and other documents.
Another thing is that many people have implemented their own little helper scripts for various purposes, which they share by email with others and those emails get lost, and nobody knows what’s the latest version of a script, etc.
We have many of such scripts already in utils. But utils got already very convoluted. So I propose to create a sub-folder, e.g. ‘dev-scripts’ to place such scripts (just for new scripts, I’m not proposing moving existing scripts). The intention is to keep the bar low to contribute to dev-scripts. So scripts may be not super-polished and it’s also ok to have multiple scripts which do similar things.
Some scripts might get attention and turn out to be useful for many people and thus get improved over time. We can eventually move such scripts out of dev-scripts into the “production” folder utils.
I agree with Jordan (and Chris) on this. I think that we should try to
simplify the build process that we have rather than encouraging more build
script wrappers. The current build process is pretty cumbersome which is
why I think that many people have wrapper scripts. In fact, it seems that
it is complicated enough that we need a wrapper script officially (aka
build-script). I think that we should aim to break down the pieces a bit
further and encourage it to be more like LLVM where even though there are
multiple projects, there is no need for a wrapper script, instead
everything works out of the box with minimal tweaks.
That said, something like Chris' idea of a bisection script seems quite
valuable, especially given the interdependencies between LLVM, clang, and
swift.
···
On Sat, Oct 21, 2017 at 9:10 AM, Chris Lattner via swift-dev < swift-dev@swift.org> wrote:
Any scripts should be subject to the same code review and design policies
as the rest of the compiler. A bisection script or build-script seem fine,
but a four line script to automate something is probably not the right
thing to include.
-Chris
> On Oct 17, 2017, at 6:05 PM, Jordan Rose via swift-dev < > swift-dev@swift.org> wrote:
>
> I always dislike wrapper scripts because it means that people are
working around undesirable behavior in a tool rather than fixing it. But
that doesn't seem to be a practical answer, because people are already
using wrapper scripts. (I've lost this argument several times before.)
>
> Jordan
>
>
>> On Oct 17, 2017, at 17:25, Erik Eckstein via swift-dev < > swift-dev@swift.org> wrote:
>>
>> I recently had some discussions about how to share those little tips
and tricks which everyone has to make building, debugging, etc. the swift
compiler easier.
>>
>> And actually we already have a central place for this: it’s the docs
folder in the swift repo. Especially the DebuggingTheCompiler.rst document
contains many useful little things which might help debugging the compiler.
>>
>> So with this email I want to “announce” this, because I found that many
people didn’t know that.
>> And also I’d like to encourage everyone to contribute to
DebuggingTheCompiler.rst and other documents.
>>
>> Another thing is that many people have implemented their own little
helper scripts for various purposes, which they share by email with others
and those emails get lost, and nobody knows what’s the latest version of a
script, etc.
>> We have many of such scripts already in utils. But utils got already
very convoluted. So I propose to create a sub-folder, e.g. ‘dev-scripts’ to
place such scripts (just for new scripts, I’m not proposing moving existing
scripts). The intention is to keep the bar low to contribute to
dev-scripts. So scripts may be not super-polished and it’s also ok to have
multiple scripts which do similar things.
>> Some scripts might get attention and turn out to be useful for many
people and thus get improved over time. We can eventually move such scripts
out of dev-scripts into the “production” folder utils.
>>
>> Please let me know if you have any comments.
>>
>> Thanks,
>> Erik
>>
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>
> _______________________________________________
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
I agree that fixing build-script is the better approach than to introduce another wrapper around it.
But there are many other needs for scripts, for example the (already existing) cmpcodesize script for comparing code size.
And I think it makes sense to create a new directory rather than putting all scripts into utils.
···
On Oct 22, 2017, at 2:58 PM, Saleem Abdulrasool via swift-dev <swift-dev@swift.org> wrote:
I agree with Jordan (and Chris) on this. I think that we should try to simplify the build process that we have rather than encouraging more build script wrappers. The current build process is pretty cumbersome which is why I think that many people have wrapper scripts. In fact, it seems that it is complicated enough that we need a wrapper script officially (aka build-script). I think that we should aim to break down the pieces a bit further and encourage it to be more like LLVM where even though there are multiple projects, there is no need for a wrapper script, instead everything works out of the box with minimal tweaks.
That said, something like Chris' idea of a bisection script seems quite valuable, especially given the interdependencies between LLVM, clang, and swift.
On Sat, Oct 21, 2017 at 9:10 AM, Chris Lattner via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
Any scripts should be subject to the same code review and design policies as the rest of the compiler. A bisection script or build-script seem fine, but a four line script to automate something is probably not the right thing to include.
-Chris
> On Oct 17, 2017, at 6:05 PM, Jordan Rose via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>
> I always dislike wrapper scripts because it means that people are working around undesirable behavior in a tool rather than fixing it. But that doesn't seem to be a practical answer, because people are already using wrapper scripts. (I've lost this argument several times before.)
>
> Jordan
>
>
>> On Oct 17, 2017, at 17:25, Erik Eckstein via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>>
>> I recently had some discussions about how to share those little tips and tricks which everyone has to make building, debugging, etc. the swift compiler easier.
>>
>> And actually we already have a central place for this: it’s the docs folder in the swift repo. Especially the DebuggingTheCompiler.rst document contains many useful little things which might help debugging the compiler.
>>
>> So with this email I want to “announce” this, because I found that many people didn’t know that.
>> And also I’d like to encourage everyone to contribute to DebuggingTheCompiler.rst and other documents.
>>
>> Another thing is that many people have implemented their own little helper scripts for various purposes, which they share by email with others and those emails get lost, and nobody knows what’s the latest version of a script, etc.
>> We have many of such scripts already in utils. But utils got already very convoluted. So I propose to create a sub-folder, e.g. ‘dev-scripts’ to place such scripts (just for new scripts, I’m not proposing moving existing scripts). The intention is to keep the bar low to contribute to dev-scripts. So scripts may be not super-polished and it’s also ok to have multiple scripts which do similar things.
>> Some scripts might get attention and turn out to be useful for many people and thus get improved over time. We can eventually move such scripts out of dev-scripts into the “production” folder utils.
>>
>> Please let me know if you have any comments.
>>
>> Thanks,
>> Erik
>>
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev@swift.org <mailto:swift-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev
>
> _______________________________________________
> swift-dev mailing list
> swift-dev@swift.org <mailto:swift-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev