Re: [rust-dev] RFC: Future of the Build System
On Wed, 15 Jan, 2014 at 15:34:29 GMT, Gaetan wrote: I just hate the if/elseif/else block in CMake list, that's all :) If you're referring to the: if (long expr) else (long expr) endif (long expr) ugliness, the 'else' and 'endif' arguments can now be empty (and really should be). --Ben ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
On 15/01/14 06:34, Corey Richardson wrote: On Tue, Jan 14, 2014 at 6:54 PM, Lee Braiden leebr...@gmail.com wrote: On 14/01/14 23:43, Corey Richardson wrote: This thread is deviating from its purpose. The idea isn't to hash out a generic build system for all of Rust, merely for the compiler + stdlib. I think it naturally progressed, because some people wanted to discuss a more generic solution. But fair enough... if the only goal is to build rust, I've very little preference, except to say: I don't mean to squash discussion. I think the build system the wider ecosystem uses is important. But that can happen in another thread; this RFC is unrelated and has a much narrow scope and wider set of requirements. From the thread I it seems we want a custom solution, in Rust, that plugs into something like Ninja. I think our dep management is simple enough that this can work very well. (In particular, we don't have the madness of header deps + each file being a compilation unit) For the Rust toolchain's purposes, we could write a simple script to generate template-based buildfiles (for want of a better word) for one/more build tools (depending on whether you want to generate all and have them choose, or generate the first that seems sensible for that platform / available tools on system): make, XCode, Visual Studio... I'm thinking of a file with a few variables, and a script that applies those to a template, perhaps with a bit of logic to decide which template to use, and which output filename to generate, and perhaps adding a few variables gleaned from the system / command line, at runtime. Probably 100 lines of python, plus templates; a bit more to make it highly usable. Not sure what the equivalent would be in Rust code, as I'm still fairly new to it. I think the first step to getting a build tool written in rust though, would be to bring back the rust run command. -- Lee ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
This is why I am reserving commentation right now and have been consistently asking about Rust providing a build system in all other emails. Can the other commenters refocus with the rest of us back to the original question? Corey Richardson co...@octayn.net wrote: On Tue, Jan 14, 2014 at 5:33 PM, Lee Braiden leebr...@gmail.com wrote: Another point is that we don't really need a massively complicated build system right now, as far as I know. I don't know rust well yet, but it's a two-line script to load this data (excluding comments). Another few lines to figure out whether to build a library or an executable, another few to run rustc with the list of files, OR to output that list to a Makefile, or a CMakeList.txt, or an IDE project file. This thread is deviating from its purpose. The idea isn't to hash out a generic build system for all of Rust, merely for the compiler + stdlib. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
Probably 100 lines of python, plus templates; a bit more to make it highly usable. Not sure what the equivalent would be in Rust code, as I'm still fairly new to it. Maybe the initial version - then you add logic to deal with different versions of Xcode/Visual Studio etc, then some more logic to find different packages that rust requires to build on a multitude of systems etc. etc. Sometimes you can get away writing something new and simple that just deals with your use case (building Rust here). The problem is if you end up with lots of feature creep re-discovering all the knowledge that is encoded in existing tools - eg. the many modules for config checks, locating packages etc. that come with CMake, automake, SCons etc. By all means, have a go at writing that initial version and see how well it serves you - but be prepared to switch if it looks like you are re-inventing something that already exists. On 21 October 2013 12:43, George Makrydakis irrequie...@gmail.com wrote: This is why I am reserving commentation right now and have been consistently asking about Rust providing a build system in all other emails. Can the other commenters refocus with the rest of us back to the original question? Corey Richardson co...@octayn.net wrote: On Tue, Jan 14, 2014 at 5:33 PM, Lee Braiden leebr...@gmail.com wrote: Another point is that we don't really need a massively complicated build system right now, as far as I know. I don't know rust well yet, but it's a two-line script to load this data (excluding comments). Another few lines to figure out whether to build a library or an executable, another few to run rustc with the list of files, OR to output that list to a Makefile, or a CMakeList.txt, or an IDE project file. This thread is deviating from its purpose. The idea isn't to hash out a generic build system for all of Rust, merely for the compiler + stdlib. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
I agree. If you take this path, use Cmake or scons. - Gaetan 2014/1/15 Robert Knight robertkni...@gmail.com Probably 100 lines of python, plus templates; a bit more to make it highly usable. Not sure what the equivalent would be in Rust code, as I'm still fairly new to it. Maybe the initial version - then you add logic to deal with different versions of Xcode/Visual Studio etc, then some more logic to find different packages that rust requires to build on a multitude of systems etc. etc. Sometimes you can get away writing something new and simple that just deals with your use case (building Rust here). The problem is if you end up with lots of feature creep re-discovering all the knowledge that is encoded in existing tools - eg. the many modules for config checks, locating packages etc. that come with CMake, automake, SCons etc. By all means, have a go at writing that initial version and see how well it serves you - but be prepared to switch if it looks like you are re-inventing something that already exists. On 21 October 2013 12:43, George Makrydakis irrequie...@gmail.com wrote: This is why I am reserving commentation right now and have been consistently asking about Rust providing a build system in all other emails. Can the other commenters refocus with the rest of us back to the original question? Corey Richardson co...@octayn.net wrote: On Tue, Jan 14, 2014 at 5:33 PM, Lee Braiden leebr...@gmail.com wrote: Another point is that we don't really need a massively complicated build system right now, as far as I know. I don't know rust well yet, but it's a two-line script to load this data (excluding comments). Another few lines to figure out whether to build a library or an executable, another few to run rustc with the list of files, OR to output that list to a Makefile, or a CMakeList.txt, or an IDE project file. This thread is deviating from its purpose. The idea isn't to hash out a generic build system for all of Rust, merely for the compiler + stdlib. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
+1, even more than that. Corey Richardson co...@octayn.net wrote: On Tue, Jan 14, 2014 at 6:54 PM, Lee Braiden leebr...@gmail.com wrote: On 14/01/14 23:43, Corey Richardson wrote: This thread is deviating from its purpose. The idea isn't to hash out a generic build system for all of Rust, merely for the compiler + stdlib. I think it naturally progressed, because some people wanted to discuss a more generic solution. But fair enough... if the only goal is to build rust, I've very little preference, except to say: I don't mean to squash discussion. I think the build system the wider ecosystem uses is important. But that can happen in another thread; this RFC is unrelated and has a much narrow scope and wider set of requirements. From the thread I it seems we want a custom solution, in Rust, that plugs into something like Ninja. I think our dep management is simple enough that this can work very well. (In particular, we don't have the madness of header deps + each file being a compilation unit) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
As an interim solution, any proven build system will do regardless of preference. Given the current status quo of Rust's evolving condition, the choice should weigh on the side compatible with what the core developers use since they build way too often. Simplify the build process by reducing number of tools required, going towards a single tool if possible. That would make the option of rusting an alternative, future solution far easier to adopt if that would still be an option. Should a poll be made instead of these threads? Lee Braiden leebr...@gmail.com wrote: On 14/01/14 23:43, Corey Richardson wrote: This thread is deviating from its purpose. The idea isn't to hash out a generic build system for all of Rust, merely for the compiler + stdlib. I think it naturally progressed, because some people wanted to discuss a more generic solution. But fair enough... if the only goal is to build rust, I've very little preference, except to say: Please choose something cross-platform that's as standard as possible, and leads to builds as simple as make or configure make or something along those lines. At the outside, CMake's cmake -G 'Unix Makefiles' etc. is tolerable (for me), in the name of supporting IDE users. -- Lee ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
To answer to this RFC, I don't see what will be improved if cmake where used. The makefile macro may be rewritten in CMakeList.txt stuff, but this will still generate makefiles and thus don't solve the compilation time. I'm curious about ninjahttp://martine.github.io/ninja/manual.html#_philosophical_overview, it is its promise to provide a simple, clean, super-fast Make. It has been made to replace the old Makefiles and even scons files to build google chrome. And moreover, it follows the UNIX principles: do one thing but do it well. It's adviced to use a meta build sytem like CMake or gyp. Does anyone has ever used ninja intensively? And then, a rust meta build program could be written to replace this metabuilder (i.e. cmake), without having to rewrite the complete ninja layer (I suppose there will be some ninja module to write to answer some issues). And see if at the end the ninja build layer can be replaced completely by a rust one. Arg, as I unroll my idea i see that it is exactly the proposal 3 in the original email... For me, poll will not give the necessary feedback about any system, merely personal point of view. Maybe it's a good start. A good deliverable should be to generate some small reports with presentation, pro, cons... the most applicable to the compilation of the rust compiler and then vote can happen. I've opened a doodle here http://doodle.com/3ngkb9ms9gt2qrap. - Gaetan 2014/1/15 George Makrydakis irrequie...@gmail.com As an interim solution, any proven build system will do regardless of preference. Given the current status quo of Rust's evolving condition, the choice should weigh on the side compatible with what the core developers use since they build way too often. Simplify the build process by reducing number of tools required, going towards a single tool if possible. That would make the option of rusting an alternative, future solution far easier to adopt if that would still be an option. Should a poll be made instead of these threads? Lee Braiden leebr...@gmail.com wrote: On 14/01/14 23:43, Corey Richardson wrote: This thread is deviating from its purpose. The idea isn't to hash out a generic build system for all of Rust, merely for the compiler + stdlib. I think it naturally progressed, because some people wanted to discuss a more generic solution. But fair enough... if the only goal is to build rust, I've very little preference, except to say: Please choose something cross-platform that's as standard as possible, and leads to builds as simple as make or configure make or something along those lines. At the outside, CMake's cmake -G 'Unix Makefiles' etc. is tolerable (for me), in the name of supporting IDE users. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
used. The makefile macro may be rewritten in CMakeList.txt stuff, but this will still generate makefiles and thus don't solve the compilation time. Our Makefiles are quite inferior to the ones that CMake generates. For example, if you run `make` on an up to date servo tree, it takes several seconds. If you run `make` on an up to date Servo tree where the makefiles are generated by CMake, it is substantially faster. Like 0.3s or so. I didn't do a full port to CMake but I was surprised at how bad our build currently was. Not only that but our hand written Makefiles are pretty loose about dependency calculation and tracking, especially across submodule boundaries. There's lots of file globs and very little attention paid to C headers. Both of these CMake solves. The fact that we often see people getting decoder ICEs in rustc is a testament to just how unreliable the current system is. Every new submodule we add and every new flag just increases this problem. Writing make abstractions is tedious an difficult. Writing them in nearly anything else would be easier. I mean, you are right that it won't fix LLVM optimization passes, so the Rust compiler's build time won't change much, but the output should be substantially more reliable. It might make a noticeable difference to those doing a lot of compiler dev work due to the quicker invocations of the tool. I'm curious about ninja, it is its promise to provide a simple, clean, super-fast Make. It has been made to replace the old Makefiles and even scons files to build google chrome. Ninja is pretty fast, but CMake's generated Makefiles are probably not far off on a project of our size. The place where this difference is most noticeable is on builds of an up to date tree. One reason it is fast, and also the reason it needs a generator, is that it makes no decisions at runtime. There is no branching, etc, just the dependency info and the commandlines to generate the build products. Note that CMake also removes the need for autotools, which is a blessing in itself. You may not like CMake's language, but I'll take it over m4 any day. jack. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
On 1/14/14 1:29 AM, comex wrote: On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis irrequie...@gmail.com wrote: Again, note that this rather long thread is about discussing in the end what the official stance should be. There is no valid reason other than lack of manpower and / or language immaturity for having to depend on ruby, python, autotools, cmake or whatever else in order to build rust software. There is no reason every language should have its own build system written from scratch (or package manager, for that matter); the goals of each language community are really mostly identical, and the existing duplication leads to software that's worse than it has to be (e.g. inconsistent support for signed packages), a waste of time relearning the same concepts for multiple build systems / package managers, and difficulty for packages that include code written in multiple languages. Meanwhile, satisfying the dependencies you mentioned is trivial on most systems. However, I'd say there is a stunning lack of existing build systems that actually combine a clean design, flexibility, portability, and performance. autotools fails badly on design, performance, and (ironically) portability; cmake fails on design (seriously, try to read any cmake script) and flexibility (a lot of stuff is hard coded in C++ and hard to change); most of the alternatives I know about are at least slow, and often poorly maintained, insufficiently general, et cetera. The only build tool I really like is ninja, and it's designed to be used with input generated from a separate tool rather than alone. So I'd personally like to see a new build system regardless. This e-mail sums up my feelings to a T, and it's why I'm conflicted about the whole matter. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
Already too much I guess. Gaetan gae...@xeberon.net wrote: rust need llvm, make, wget, bash script, python, autotools... it's just a matter of choice of which external tool you accept to rely on - Gaetan 2014/1/14 George Makrydakis irrequie...@gmail.com Lack of manpower. Correct. As I have written elsewhere in these threads, this is why an interim solution of a third party tool should perhaps be choosen, instead of sactioning a build system in any language relic X as the official tool. Closer to 1.0, the need will become more apparent. I do not see a task team / working group proposing this and in order for any official guideline to be followed, this is a step to be taken. Wasn't this the purpose of this thread? Perhaps this is what comex is trying to say, albeit with his own peculiar rhetorical structure - I doubt that anybody is trolling, knowingly. I still think that for the intended scope, Rust should just need Rust. Gaetan gae...@xeberon.net wrote: However, I'd say there is a stunning lack of existing build systems that actually combine a clean design, flexibility, portability, and performance. autotools fails badly on design, performance, and (ironically) portability; cmake fails on design (seriously, try to read any cmake script) Same than any language, you can write bloated code or quite pretty things. Just be consistent and think reusability and flexibility (a lot of stuff is hard coded in C++ and hard to change); I don't see what you say is hardcoded? At worst, I simply had to rewrite a import module. most of the alternatives I know about are at least slow, and often poorly maintained, insufficiently general, et cetera. The only build tool I really like is ninja, and it's designed to be used with input generated from a separate tool rather than alone. So I'd personally like to see a new build system regardless. I also agree that having a proper build system sounds sexy, however do the rust dev team has enough man power for that? Why not try to assemble a task that will evaluate several existing build system instead of just trolling in this thread, to see exactly what are the advantages and flaws of each candidates? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
Then, as we discuss on the replies to this, shouldn't there be a task force dealing with the matter for what it concerns Rust? Personal preferences lead to conflicts; reaching a consensus requires a wider set of options discussed inproper setting and community audience. So far, there is little more presented here than personal preferences. These could be used as a basis for what the definitive solution to this matter should be. Patrick Walton pcwal...@mozilla.com wrote: On 1/14/14 1:29 AM, comex wrote: On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis irrequie...@gmail.com wrote: Again, note that this rather long thread is about discussing in the end what the official stance should be. There is no valid reason other than lack of manpower and / or language immaturity for having to depend on ruby, python, autotools, cmake or whatever else in order to build rust software. There is no reason every language should have its own build system written from scratch (or package manager, for that matter); the goals of each language community are really mostly identical, and the existing duplication leads to software that's worse than it has to be (e.g. inconsistent support for signed packages), a waste of time relearning the same concepts for multiple build systems / package managers, and difficulty for packages that include code written in multiple languages. Meanwhile, satisfying the dependencies you mentioned is trivial on most systems. However, I'd say there is a stunning lack of existing build systems that actually combine a clean design, flexibility, portability, and performance. autotools fails badly on design, performance, and (ironically) portability; cmake fails on design (seriously, try to read any cmake script) and flexibility (a lot of stuff is hard coded in C++ and hard to change); most of the alternatives I know about are at least slow, and often poorly maintained, insufficiently general, et cetera. The only build tool I really like is ninja, and it's designed to be used with input generated from a separate tool rather than alone. So I'd personally like to see a new build system regardless. This e-mail sums up my feelings to a T, and it's why I'm conflicted about the whole matter. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
On 14/01/14 17:25, Patrick Walton wrote:
On 1/14/14 1:29 AM, comex wrote:
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
irrequie...@gmail.com wrote:
Again, note that this rather long thread is about discussing in the
end what
the official stance should be. There is no valid reason other than
lack of
manpower and / or language immaturity for having to depend on ruby,
python,
autotools, cmake or whatever else in order to build rust software.
There is no reason every language should have its own build system
written from scratch (or package manager, for that matter); the goals
of each language community are really mostly identicalsnip
However, I'd say there is a stunning lack of existing build systems
that actually combine a clean design, flexibility, portability, and
performancesnip
This e-mail sums up my feelings to a T, and it's why I'm conflicted
about the whole matter.
The more people talk about different build systems and how we can't
choose one yet, the more I agree.
So, rethinking, it seems to me that important part seems, is to be
COMPATIBLE with everyone's project hosting, build system, and/or package
manager of choice. That would include command line build tools, pretty
website download catalogs, yum, synaptic, cabal, etc.
So, much more important than choosing TOOLS, I think Rust needs to
standardise INFORMATION that any tool can use. Perhaps something like this?
[
project: {
name: someproject,
brief-description: some description,
limited-description: [
Para-one.,
Para-two.,
Para-three.
],
web: http://buggysoft.com;,
screenshots:{
screenshot one: {
uri: http://www.buggypics.com/massivebug.png;,
alt-text: Features massive bugs,
},
},
bug-tickets: http://overloaded-cloud-system.buggysoft.com;,
authors: {
author1: {
email:auth...@someplace.com,
web: http://someplace.com;,
},
},
copyright: {
license-file:docs/LICENSE.TXT,
license-flags:SHAREALIKE | ATTRIBUTION |
ADVERTISING_CLAUSE,
},
build-info: {
build-type:library,
target: libx.so
source-files: [ src/*.rs, somedir/a_file.rs ],
},
developer-support-info: {
rust-ide-doc-file: docs/libx.rustapi,
rust-ide-completion-file: docs/libx.rusttags,
},
dependencies: {
rust-projects: {
someotherproject: {# from that projects
project - name entry
# following fields are optional; any
specified filter the list
# the list of suitable candidates.
min-version: 0.1,
max-version: 0.1,
gitrepo:
http://somehub.com/someuser/someotherproject/;,
min-git-tag: 04a453543,
max-git-tag: 045ead634,
tarball-uri:
http://someotherproject.com/somepath-${version}.tgz;,
distro-version-ok:true
}
},
external-libs: {
libssl:{
min-version: 0.1,
max-version: 0.1,
gitrepo:
http://somehub.com/someuser/someotherproject/;,
min-git-tag: 04a453543,
max-git-tag: 045ead634,
tarball-uri:
http://someotherproject.com/somepath-${version}.tgz;
distro-version-ok:true,
}
},
}
}
]
--
Lee
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
That would be a good start. But are you advocating that it should be third
party tools thatcshould be given guidelines on how to comply? What would be
their incentive to do so? Or should this be used as a basis for creating a
prototype deploying duch information... which would inevitably ask again:
Should Rust have its own build tool, given your proposal of standardized
representational information ? Dealing with such metadata forces you to design
a new system.
Lee Braiden leebr...@gmail.com wrote:
On 14/01/14 17:25, Patrick Walton wrote:
On 1/14/14 1:29 AM, comex wrote:
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
irrequie...@gmail.com wrote:
Again, note that this rather long thread is about discussing in the
end what
the official stance should be. There is no valid reason other than
lack of
manpower and / or language immaturity for having to depend on ruby,
python,
autotools, cmake or whatever else in order to build rust software.
There is no reason every language should have its own build system
written from scratch (or package manager, for that matter); the
goals
of each language community are really mostly identicalsnip
However, I'd say there is a stunning lack of existing build systems
that actually combine a clean design, flexibility, portability, and
performancesnip
This e-mail sums up my feelings to a T, and it's why I'm conflicted
about the whole matter.
The more people talk about different build systems and how we can't
choose one yet, the more I agree.
So, rethinking, it seems to me that important part seems, is to be
COMPATIBLE with everyone's project hosting, build system, and/or
package
manager of choice. That would include command line build tools, pretty
website download catalogs, yum, synaptic, cabal, etc.
So, much more important than choosing TOOLS, I think Rust needs to
standardise INFORMATION that any tool can use. Perhaps something like
this?
[
project: {
name: someproject,
brief-description: some description,
limited-description: [
Para-one.,
Para-two.,
Para-three.
],
web: http://buggysoft.com;,
screenshots:{
screenshot one: {
uri: http://www.buggypics.com/massivebug.png;,
alt-text: Features massive bugs,
},
},
bug-tickets: http://overloaded-cloud-system.buggysoft.com;,
authors: {
author1: {
email:auth...@someplace.com,
web: http://someplace.com;,
},
},
copyright: {
license-file:docs/LICENSE.TXT,
license-flags:SHAREALIKE | ATTRIBUTION |
ADVERTISING_CLAUSE,
},
build-info: {
build-type:library,
target: libx.so
source-files: [ src/*.rs, somedir/a_file.rs ],
},
developer-support-info: {
rust-ide-doc-file: docs/libx.rustapi,
rust-ide-completion-file: docs/libx.rusttags,
},
dependencies: {
rust-projects: {
someotherproject: {# from that projects
project - name entry
# following fields are optional; any
specified filter the list
# the list of suitable candidates.
min-version: 0.1,
max-version: 0.1,
gitrepo:
http://somehub.com/someuser/someotherproject/;,
min-git-tag: 04a453543,
max-git-tag: 045ead634,
tarball-uri:
http://someotherproject.com/somepath-${version}.tgz;,
distro-version-ok:true
}
},
external-libs: {
libssl:{
min-version: 0.1,
max-version: 0.1,
gitrepo:
http://somehub.com/someuser/someotherproject/;,
min-git-tag: 04a453543,
max-git-tag: 045ead634,
tarball-uri:
http://someotherproject.com/somepath-${version}.tgz;
distro-version-ok:true,
}
},
}
}
]
--
Lee
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
On 14/01/14 20:51, George Makrydakis wrote:
That would be a good start. But are you advocating that it should be
third party tools thatcshould be given guidelines on how to comply?
What would be their incentive to do so? Or should this be used as a
basis for creating a prototype deploying duch information... which
would inevitably ask again:
Should Rust have its own build tool, given your proposal of
standardized representational information ? Dealing with such metadata
forces you to design a new system.
I guess I'm saying that, no matter what solution you choose:
a) People will want their own version, either because they know and
prefer something else, OR just because they run, say, debian, and it
manages 26000 packages on their system, and they want Rust to be managed
that way too.**
b) This kind of information will be needed
** For instance, Debian has tools to create debian packages from git
repositories, PHP's pear packages, perl packages, google earth tarballs,
etc.
Arch, BSD ports, and the like import packages using a thin wrapper
around whatever package system upstream developers use. There's a will,
in Linux, in Mac, with MacPorts, in cygwin, etc., and in mobile, to
integrate package management into one system for all. We don't
necessarily have to provide build tools for each platform, so
integration tools for each IDE, syntax highlighting for each editor, or
API documentation/tags for each IDE. At least, to start with, all we
need to do is make it possible for people who want to do these things,
to do them.
But, what I think is pretty important, is to establish the standard as
early as possible, to allow people to build tools for as many Rust
packages as possible. In many ways, speaking as a general developer
rather than a rust developer, knowing that any rust package / repository
will contain a .rust-info file, say, which tells me all the metadata I
need to know to integrate that package into my website, buildtool, or
whatever... that's much more valuable to me, than knowing that I can
download some package, on any of 3 platforms, and it'll just just
build. The tool is short term convenience, but the data lets me build
short term tools AND long-term infrastructure.
--
Lee
Lee Braiden leebr...@gmail.com wrote:
On 14/01/14 17:25, Patrick Walton wrote:
On 1/14/14 1:29 AM, comex wrote:
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
irrequie...@gmail.com wrote:
Again, note that this rather long thread is about
discussing in the end what the official stance should
be. There is no valid reason other than lack of
manpower and / or language immaturity for having to
depend on ruby, python, autotools, cmake or whatever
else in order to build rust software.
There is no reason every language should have its own
build system written from scratch (or package manager, for
that matter); the goals of each language community are
really mostly identicalsnip However, I'd say there is a
stunning lack of existing build systems that actually
combine a clean design, flexibility, portability, and
performancesnip
This e-mail sums up my feelings to a T, and it's why I'm
conflicted about the whole matter.
The more people talk about different build systems and how we can't
choose one yet, the more I agree.
So, rethinking, it seems to me that important part seems, is to be
COMPATIBLE with everyone's project hosting, build system, and/or package
manager of choice. That would include command line build tools, pretty
website download catalogs, yum, synaptic, cabal, etc.
So, much more important than choosing TOOLS, I think Rust needs to
standardise INFORMATION that any
tool can use. Perhaps something like this?
[
project: {
name: someproject,
brief-description: some description,
limited-description: [
Para-one.,
Para-two.,
Para-three.
],
web: http://buggysoft.com;,
screenshots:{
screenshot one: {
uri: http://www.buggypics.com/massivebug.png;,
alt-text: Features massive bugs,
},
},
bug-tickets: http://overloaded-cloud-system.buggysoft.com;,
authors: {
author1: {
email:auth...@someplace.com,
web: http://someplace.com;,
},
},
copyright: {
license-file:docs/LICENSE.TXT,
license-flags:SHAREALIKE | ATTRIBUTION |
ADVERTISING_CLAUSE,
Re: [rust-dev] RFC: Future of the Build System
this looks like POM :)
I always dreamt of writing a proper build system with such high level
structure, deal with project dependencies, but that is way more complex
than that.
if a project in rust start with this matter, I volunteer to participate to
it.
-
Gaetan
2014/1/14 Lee Braiden leebr...@gmail.com
On 14/01/14 17:25, Patrick Walton wrote:
On 1/14/14 1:29 AM, comex wrote:
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
irrequie...@gmail.com wrote:
Again, note that this rather long thread is about discussing in the end
what
the official stance should be. There is no valid reason other than lack
of
manpower and / or language immaturity for having to depend on ruby,
python,
autotools, cmake or whatever else in order to build rust software.
There is no reason every language should have its own build system
written from scratch (or package manager, for that matter); the goals
of each language community are really mostly identicalsnip
However, I'd say there is a stunning lack of existing build systems
that actually combine a clean design, flexibility, portability, and
performancesnip
This e-mail sums up my feelings to a T, and it's why I'm conflicted about
the whole matter.
The more people talk about different build systems and how we can't choose
one yet, the more I agree.
So, rethinking, it seems to me that important part seems, is to be
COMPATIBLE with everyone's project hosting, build system, and/or package
manager of choice. That would include command line build tools, pretty
website download catalogs, yum, synaptic, cabal, etc.
So, much more important than choosing TOOLS, I think Rust needs to
standardise INFORMATION that any tool can use. Perhaps something like this?
[
project: {
name: someproject,
brief-description: some description,
limited-description: [
Para-one.,
Para-two.,
Para-three.
],
web: http://buggysoft.com;,
screenshots:{
screenshot one: {
uri: http://www.buggypics.com/massivebug.png;,
alt-text: Features massive bugs,
},
},
bug-tickets: http://overloaded-cloud-system.buggysoft.com;,
authors: {
author1: {
email:auth...@someplace.com,
web: http://someplace.com;,
},
},
copyright: {
license-file:docs/LICENSE.TXT,
license-flags:SHAREALIKE | ATTRIBUTION |
ADVERTISING_CLAUSE,
},
build-info: {
build-type:library,
target: libx.so
source-files: [ src/*.rs, somedir/a_file.rs ],
},
developer-support-info: {
rust-ide-doc-file: docs/libx.rustapi,
rust-ide-completion-file: docs/libx.rusttags,
},
dependencies: {
rust-projects: {
someotherproject: {# from that projects
project - name entry
# following fields are optional; any specified
filter the list
# the list of suitable candidates.
min-version: 0.1,
max-version: 0.1,
gitrepo: http://somehub.com/someuser/
someotherproject/,
min-git-tag: 04a453543,
max-git-tag: 045ead634,
tarball-uri: http://someotherproject.com/
somepath-${version}.tgz,
distro-version-ok:true
}
},
external-libs: {
libssl:{
min-version: 0.1,
max-version: 0.1,
gitrepo: http://somehub.com/someuser/
someotherproject/,
min-git-tag: 04a453543,
max-git-tag: 045ead634,
tarball-uri: http://someotherproject.com/
somepath-${version}.tgz
distro-version-ok:true,
}
},
}
}
]
--
Lee
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
Another point is that we don't really need a massively complicated
build system right now, as far as I know.
I don't know rust well yet, but it's a two-line script to load this data
(excluding comments). Another few lines to figure out whether to build
a library or an executable, another few to run rustc with the list of
files, OR to output that list to a Makefile, or a CMakeList.txt, or an
IDE project file.
With the data, you could build any tool of your choice, to use (almost)
any tool of your choice, with a few lines in the language of your choice.
And, you can evolve it all later, into something better. And the data
format could be extended too. I should add that the data format should
have a version number, so tools could parse new versions differently, or
even read this file, see that it's version 2, and that a better, more
file format with a different filename should be used instead.
--
Lee
On 14/01/14 20:51, George Makrydakis wrote:
That would be a good start. But are you advocating that it should be
third party tools thatcshould be given guidelines on how to comply?
What would be their incentive to do so? Or should this be used as a
basis for creating a prototype deploying duch information... which
would inevitably ask again:
Should Rust have its own build tool, given your proposal of
standardized representational information ? Dealing with such metadata
forces you to design a new system.
Lee Braiden leebr...@gmail.com wrote:
On 14/01/14 17:25, Patrick Walton wrote:
On 1/14/14 1:29 AM, comex wrote:
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
irrequie...@gmail.com wrote:
Again, note that this rather long thread is about
discussing in the end what the official stance should
be. There is no valid reason other than lack of
manpower and / or language immaturity for having to
depend on ruby, python, autotools, cmake or whatever
else in order to build rust software.
There is no reason every language should have its own
build system written from scratch (or package manager, for
that matter); the goals of each language community are
really mostly identicalsnip However, I'd say there is a
stunning lack of existing build systems that actually
combine a clean design, flexibility, portability, and
performancesnip
This e-mail sums up my feelings to a T, and it's why I'm
conflicted about the whole matter.
The more people talk about different build systems and how we can't
choose one yet, the more I agree.
So, rethinking, it seems to me that important part seems, is to be
COMPATIBLE with everyone's project hosting, build system, and/or package
manager of choice. That would include command line build tools, pretty
website download catalogs, yum, synaptic, cabal, etc.
So, much more important than choosing TOOLS, I think Rust needs to
standardise INFORMATION that any
tool can use. Perhaps something like this?
[
project: {
name: someproject,
brief-description: some description,
limited-description: [
Para-one.,
Para-two.,
Para-three.
],
web: http://buggysoft.com;,
screenshots:{
screenshot one: {
uri: http://www.buggypics.com/massivebug.png;,
alt-text: Features massive bugs,
},
},
bug-tickets: http://overloaded-cloud-system.buggysoft.com;,
authors: {
author1: {
email:auth...@someplace.com,
web: http://someplace.com;,
},
},
copyright: {
license-file:docs/LICENSE.TXT,
license-flags:SHAREALIKE | ATTRIBUTION |
ADVERTISING_CLAUSE,
},
build-info: {
build-type:library,
target: libx.so http://libx.so
source-files: [ src/*.rs, somedir/a_file.rs
http://file.rs ],
},
developer-support-info: {
rust-ide-doc-file: docs/libx.rustapi,
rust-ide-completion-file: docs/libx.rusttags,
},
dependencies: {
rust-projects: {
someotherproject: {# from that projects
project - name
entry
# following fields are optional; any
specified filter the list
# the list of suitable candidates.
min-version:
Re: [rust-dev] RFC: Future of the Build System
Gaetan, I agree, it's important to think of use cases up-front, and I've tried to do that below, too. If you can add any necessary features or ideas, please do. And if Rustics reach consensus that this is the preferred approach, then we should definitely formalise the decision process about selecting use cases, making sure they're all covered, etc. However, from experience, it's IMPOSSIBLE to think of EVERY use case up front. Simply not knowing what technology will be invented in five years prevents it. No matter how hard you try to envisage all circumstances, and all future use-cases, something will just be obviously missing, in hindsight. The best standards ALWAYS tag versions, and leave room for forwards-compatible upgrades. It's the very reason we have to deal with packages for lots of different library versions: eventually, you want to deprecate old stuff, and embrace new stuff, and you need some version number to tell which is which. This shouldn't be threatening; it's the EASY, SAFE, GENTLE way to add new features. It's what every sensible protocol and standard on the internet does, for instance, right down to IP itself. -- Lee On 14/01/14 22:35, Gaetan wrote: i disagree, the data structure needs to be developed with the majority of use case possible. you cannot rely on just extending it later when new feature will be needed, that will NOT work. - Gaetan 2014/1/14 Lee Braiden leebr...@gmail.com mailto:leebr...@gmail.com Another point is that we don't really need a massively complicated build system right now, as far as I know. I don't know rust well yet, but it's a two-line script to load this data (excluding comments). Another few lines to figure out whether to build a library or an executable, another few to run rustc with the list of files, OR to output that list to a Makefile, or a CMakeList.txt, or an IDE project file. With the data, you could build any tool of your choice, to use (almost) any tool of your choice, with a few lines in the language of your choice. And, you can evolve it all later, into something better. And the data format could be extended too. I should add that the data format should have a version number, so tools could parse new versions differently, or even read this file, see that it's version 2, and that a better, more file format with a different filename should be used instead. -- Lee On 14/01/14 20:51, George Makrydakis wrote: That would be a good start. But are you advocating that it should be third party tools thatcshould be given guidelines on how to comply? What would be their incentive to do so? Or should this be used as a basis for creating a prototype deploying duch information... which would inevitably ask again: Should Rust have its own build tool, given your proposal of standardized representational information ? Dealing with such metadata forces you to design a new system. Lee Braiden leebr...@gmail.com mailto:leebr...@gmail.com wrote: On 14/01/14 17:25, Patrick Walton wrote: On 1/14/14 1:29 AM, comex wrote: On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis irrequie...@gmail.com mailto:irrequie...@gmail.com wrote: Again, note that this rather long thread is about discussing in the end what the official stance should be. There is no valid reason other than lack of manpower and / or language immaturity for having to depend on ruby, python, autotools, cmake or whatever else in order to build rust software. There is no reason every language should have its own build system written from scratch (or package manager, for that matter); the goals of each language community are really mostly identicalsnip However, I'd say there is a stunning lack of existing build systems that actually combine a clean design, flexibility, portability, and performancesnip This e-mail sums up my feelings to a T, and it's why I'm conflicted about the whole matter. The more people talk about different build systems and how we can't choose one yet, the more I agree. So, rethinking, it seems to me that important part seems, is to be COMPATIBLE with everyone's project hosting, build system, and/or package manager of choice. That would include command line build tools, pretty website download catalogs, yum, synaptic, cabal, etc. So, much more important than choosing TOOLS, I think Rust needs to standardise INFORMATION that any tool can use. Perhaps something like this? [
Re: [rust-dev] RFC: Future of the Build System
i read the ninja documentation, and this integrates well with cmake, and do the majority of the graph stuff required to compile file. i kind of like it. and i wonder why rust-pkg cannot be extended, for simple project to generate ninja files... - Gaetan 2014/1/15 Lee Braiden leebr...@gmail.com On 14/01/14 22:51, Gaetan wrote: you cannot stick build environment with one system. apt is now on every system, you cannot use it under windows or mac. I think you're misunderstanding me. I don't favor debian in any way. I would like debian people (and windows people, and mac people, and BSD people, and cloud deployment people, etc.) to be able to use Rust packages in whatever why they choose, though. and apt source simply checkout the source zip from repository, this is not a proper build system. This is getting off topic, but no, apt-get source builds source code that's already been patched with package information. It's exactly how debian builds its packages for general use. package management is one job and build is another one. you will use another package management on another system, while you expect to use the same build system on another system. That's true IF your package manager only supports third-party binaries. However, if your package manager includes some build process, as most emphatically DO, then I believe that's incorrect. However, I understand that you're saying we shouldn't rely on particular package managers. That is NOT my intention -- just the opposite :) in my experience, i ended up quite often with some bash script for unix like systems that generates some makefiles or trigs cmake/cpack, visual studio or eclipse projects for windows. the only portable build system i used was cmake, which exists under windows mac and unit, with ctest and cpack, even if there are quite limited. And there were a lot of if windows... Yes, this is what I'm saying :) But, i tend to NOT recommend cmake if the final goal is to be integrated into systems like debian. The final goal would be to allow every distro, every operating system, every continuous integration system, every shell script, every cloud image builder, every mobile phone developer, and custom OS writer, do work with Rust packages in whatever way suits them best. -- Lee ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
what about using a well known build system as a transition to a custom, rust-written build tool? If this is not planned in rust roadmap, I can't see how this will work. For me it's the same old dilemna: write my tool or use an existing one? Same for doc... should we use sphinx or write a customized tool? - Gaetan 2014/1/11 George Makrydakis irrequie...@gmail.com There is little reason to believe that having a build system in Rust would make It harder for people to package. I do understand the predependecy argument, but the Rust compiler itself in order to compile has predependencies anyway, as does any similar project. Therefore the decisional weight of choosing a non - rust based solution over a rust one because Debian packagers have problems packaging a compiler is not adequately justified. Using a well known build system as a means to appeal to programmers is seemingly an advantage, but it does not exonerate them from having to be competent in Rust before they write useful programs. And that has a learning curve superior to that of a build system. As for boost's jam I have nothing to say other than boost having its own build system makes it easy for boost first; this does not mean that their needs are those of everybody else and boost is a library, not a programming language itself. So, again, a decision based on picking a popular solution on the basis of such a comparison, has flawed background. Lastly, imagine the irony of Rust proposing to use python, c, c++ based build tools for simple packages. That would make packagers more frustrated because of a wider set of dependecies. While end users would have to also deal with a known system, its eventual inadequacies could not be met directly by Rust devs unless they start amending that system in order to deal with them. Therefore, maintenance overhead is inescapable either way, with the pessimization of relying in another nom - Rust project in order to make it worth your while to enjoy programming in Rust. The only valid argument against having a build system proposed as the official, defacto, cross - platform way of building rust packages written in rust is its development and maintenance overhead for the rust core team itself. That problem is easily circumvented by not proposing one right now and letting it to the end developer decide. If however an official build system is to be proposed, Rust developers merit having it done on their own platform, thus proving rust's worth. It is 2014 after all. G. Lee Braiden leebr...@gmail.com wrote: On 10/01/14 08:16, Gaetan wrote: I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. I'd agree with that on both counts: the principle of using something standard, and the two recommendations. CMake would probably get my vote, because it's not so much a build tool, as a meta tool for whichever system you prefer, so it would fit in well with various platform-specific IDEs, unusual platforms (android, embedded, ...), etc. That said, scons is also a strong contender, and which of the two is more open to integrating patches and working with new languages is very much worth considering. I think Rust will be contributing to the wider community by lending its support (and patches) to a common, modern build system, AND it will get something back in terms of users who already know the build system. On Friday, January 10, 2014, George Makrydakis wrote: Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon enough. Bear in mind that Debian are having a lot of issues packaging Rust already, because it self-compiles. If the build tool also had a Rust pre-dependency, that would be a big step backwards. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
2014/1/10 Corey Richardson co...@octayn.net: 3. Write a build system in Rust. This would take care of everything for us, using ourselves. We'd have a small script fetch the snapshot and build the build system, and then hand off the rest of the build to it. This has the advantage of one less build-time dependency, but the disadvantage that it's going to be a lot of work. This could also potentially output tup, ninja[3], or another form of build script after taking configuration options and so-forth. It could also integrate with librustc for smart handling of comments-or-test-only changes, an issue near to my heart[4]. This build system could potentially be rustpkg, but as I understand it the current idea is to *remove* rustpkg's ability as a build system and keep it as a package manager. (At least, that is what I've understood of recent discussion; this could be wrong.) Do you have any links of those discussions? I'm new to the mailing list. IMHO rustpkg should keep the ability of a build system. Lots of work has already been put into it and why rewrite that? I think this rust-written build tool should be rustpkg. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
Several lengthy emails have full argumentation in supporting that as an interim solution given the current status of Rust itself. It is the adoption of a third party tool, not written in rust, as the defacto standard to use with official blessing, that should be discarded for reasons already discussed. Again, note that this rather long thread is about discussing in the end what the official stance should be. There is no valid reason other than lack of manpower and / or language immaturity for having to depend on ruby, python, autotools, cmake or whatever else in order to build rust software. Is Rust capable, as a systems language, of having a build system in Rust for Rust, or it should depend on other languages, *officially* for such a thing? Personal preferences matter up to a point, but no more. Gaetan gae...@xeberon.net wrote: what about using a well known build system as a transition to a custom, rust-written build tool? If this is not planned in rust roadmap, I can't see how this will work. For me it's the same old dilemna: write my tool or use an existing one? Same for doc... should we use sphinx or write a customized tool? - Gaetan 2014/1/11 George Makrydakis irrequie...@gmail.com There is little reason to believe that having a build system in Rust would make It harder for people to package. I do understand the predependecy argument, but the Rust compiler itself in order to compile has predependencies anyway, as does any similar project. Therefore the decisional weight of choosing a non - rust based solution over a rust one because Debian packagers have problems packaging a compiler is not adequately justified. Using a well known build system as a means to appeal to programmers is seemingly an advantage, but it does not exonerate them from having to be competent in Rust before they write useful programs. And that has a learning curve superior to that of a build system. As for boost's jam I have nothing to say other than boost having its own build system makes it easy for boost first; this does not mean that their needs are those of everybody else and boost is a library, not a programming language itself. So, again, a decision based on picking a popular solution on the basis of such a comparison, has flawed background. Lastly, imagine the irony of Rust proposing to use python, c, c++ based build tools for simple packages. That would make packagers more frustrated because of a wider set of dependecies. While end users would have to also deal with a known system, its eventual inadequacies could not be met directly by Rust devs unless they start amending that system in order to deal with them. Therefore, maintenance overhead is inescapable either way, with the pessimization of relying in another nom - Rust project in order to make it worth your while to enjoy programming in Rust. The only valid argument against having a build system proposed as the official, defacto, cross - platform way of building rust packages written in rust is its development and maintenance overhead for the rust core team itself. That problem is easily circumvented by not proposing one right now and letting it to the end developer decide. If however an official build system is to be proposed, Rust developers merit having it done on their own platform, thus proving rust's worth. It is 2014 after all. G. Lee Braiden leebr...@gmail.com wrote: On 10/01/14 08:16, Gaetan wrote: I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. I'd agree with that on both counts: the principle of using something standard, and the two recommendations. CMake would probably get my vote, because it's not so much a build tool, as a meta tool for whichever system you prefer, so it would fit in well with various platform-specific IDEs, unusual platforms (android, embedded, ...), etc. That said, scons is also a strong contender, and which of the two is more open to integrating patches and working with new languages is very much worth considering. I think Rust will be contributing to the wider community by lending its support (and patches) to a common, modern build system, AND it will get something back in terms of users who already know the build system. On Friday, January 10, 2014, George Makrydakis wrote: Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon
Re: [rust-dev] RFC: Future of the Build System
rustc is just another regular Rust application. So use the tools that any other Rust application (will) use ;-) I think at some point in time there will be a capable build tool written in Rust (like there is for all the other languages). Then it would make sense to switch using it for the compiler as well. Michael Am 11.01.2014 08:56, schrieb George Makrydakis: There is little reason to believe that having a build system in Rust would make It harder for people to package. I do understand the predependecy argument, but the Rust compiler itself in order to compile has predependencies anyway, as does any similar project. Therefore the decisional weight of choosing a non - rust based solution over a rust one because Debian packagers have problems packaging a compiler is not adequately justified. Using a well known build system as a means to appeal to programmers is seemingly an advantage, but it does not exonerate them from having to be competent in Rust before they write useful programs. And that has a learning curve superior to that of a build system. As for boost's jam I have nothing to say other than boost having its own build system makes it easy for boost first; this does not mean that their needs are those of everybody else and boost is a library, not a programming language itself. So, again, a decision based on picking a popular solution on the basis of such a comparison, has flawed background. Lastly, imagine the irony of Rust proposing to use python, c, c++ based build tools for simple packages. That would make packagers more frustrated because of a wider set of dependecies. While end users would have to also deal with a known system, its eventual inadequacies could not be met directly by Rust devs unless they start amending that system in order to deal with them. Therefore, maintenance overhead is inescapable either way, with the pessimization of relying in another nom - Rust project in order to make it worth your while to enjoy programming in Rust. The only valid argument against having a build system proposed as the official, defacto, cross - platform way of building rust packages written in rust is its development and maintenance overhead for the rust core team itself. That problem is easily circumvented by not proposing one right now and letting it to the end developer decide. If however an official build system is to be proposed, Rust developers merit having it done on their own platform, thus proving rust's worth. It is 2014 after all. G. Lee Braiden leebr...@gmail.com wrote: On 10/01/14 08:16, Gaetan wrote: I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. I'd agree with that on both counts: the principle of using something standard, and the two recommendations. CMake would probably get my vote, because it's not so much a build tool, as a meta tool for whichever system you prefer, so it would fit in well with various platform-specific IDEs, unusual platforms (android, embedded, ...), etc. That said, scons is also a strong contender, and which of the two is more open to integrating patches and working with new languages is very much worth considering. I think Rust will be contributing to the wider community by lending its support (and patches) to a common, modern build system, AND it will get something back in terms of users who already know the build system. On Friday, January 10, 2014, George Makrydakis wrote: Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon enough. Bear in mind that Debian are having a lot of issues packaging Rust already, because it self-compiles. If the build tool also had a Rust pre-dependency, that would be a big step backwards. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
Indeed. I fully agree with your apt foreshadowing of events. If it is not feasible to have a rust based tool now, as long as any other tool is not given priviledged status formally speaking, using whatever ready means appropriate is a strategy that scales well within a limited time period. From this thread it seems a reasonably acceptable compromise - until a rust tool is given priority; but it is not clear if this is the actual plan. I think that discussing about the merits of other build systems should not be transmuted into an agenda of using them as the blessed defaults. Specifying this is very important for rust to be a modern, cohere platform - level solution with easy exchange of libraries among users, relying on a common environment that is compatible with the goals of Rust itself. This is why it should be fully controlled by the Rust community, thus written in Rust. Think about the merit of having such a system in rust, eventually deployed by other projects, unrelated to rust, because it ends up being *that* good. This is a matter that should be definitively discussed after Rust 1.0, when the language starts being backwards - reliable to a considerable extent. G. Michael Neumann mneum...@ntecs.de wrote: rustc is just another regular Rust application. So use the tools that any other Rust application (will) use ;-) I think at some point in time there will be a capable build tool written in Rust (like there is for all the other languages). Then it would make sense to switch using it for the compiler as well. Michael Am 11.01.2014 08:56, schrieb George Makrydakis: There is little reason to believe that having a build system in Rust would make It harder for people to package. I do understand the predependecy argument, but the Rust compiler itself in order to compile has predependencies anyway, as does any similar project. Therefore the decisional weight of choosing a non - rust based solution over a rust one because Debian packagers have problems packaging a compiler is not adequately justified. Using a well known build system as a means to appeal to programmers is seemingly an advantage, but it does not exonerate them from having to be competent in Rust before they write useful programs. And that has a learning curve superior to that of a build system. As for boost's jam I have nothing to say other than boost having its own build system makes it easy for boost first; this does not mean that their needs are those of everybody else and boost is a library, not a programming language itself. So, again, a decision based on picking a popular solution on the basis of such a comparison, has flawed background. Lastly, imagine the irony of Rust proposing to use python, c, c++ based build tools for simple packages. That would make packagers more frustrated because of a wider set of dependecies. While end users would have to also deal with a known system, its eventual inadequacies could not be met directly by Rust devs unless they start amending that system in order to deal with them. Therefore, maintenance overhead is inescapable either way, with the pessimization of relying in another nom - Rust project in order to make it worth your while to enjoy programming in Rust. The only valid argument against having a build system proposed as the official, defacto, cross - platform way of building rust packages written in rust is its development and maintenance overhead for the rust core team itself. That problem is easily circumvented by not proposing one right now and letting it to the end developer decide. If however an official build system is to be proposed, Rust developers merit having it done on their own platform, thus proving rust's worth. It is 2014 after all. G. Lee Braiden leebr...@gmail.com wrote: On 10/01/14 08:16, Gaetan wrote: I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. I'd agree with that on both counts: the principle of using something standard, and the two recommendations. CMake would probably get my vote, because it's not so much a build tool, as a meta tool for whichever system you prefer, so it would fit in well with various platform-specific IDEs, unusual platforms (android, embedded, ...), etc. That said, scons is also a strong contender, and which of the two is more open to integrating patches and working with new languages is very much worth considering. I think Rust will be contributing to the wider community by lending its support (and patches) to a common, modern build system, AND it will get something back in terms of users who already know the build system. On Friday, January 10, 2014, George Makrydakis wrote: Hello,
Re: [rust-dev] RFC: Future of the Build System
On 11/01/2014 07:56, George Makrydakis wrote: There is little reason to believe that having a build system in Rust would make It harder for people to package. Surely you just need an alternate that is a script generated as a from-clean dry run with -j1? It gives you the commands needed, in an order that works. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
On 10/01/2014 08:54, Jan Niklas Hasse wrote: Also cmake still depends on make (or even worse Visual Studio / Xcode). We use cmake with ninja at work, and that seems to work pretty well. I suggest if you want to write a tool, then you first write something that generates ninja files. Then you immediately have a bootstrap mechanism, plus something that will do builds rather quickly thereafter. scons can be (very) slow. My experience with waf was better, but I think generating a nnja script is superior and there are several tools to do that. You could look at gyp, for example. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
I would not exclude ninja from the candidates of an in - between solution for the time being. Imagine the power of ninja but implementing its conceptual machinery in expressive Rust code. It would be an interesting combination indeed. That could bring even more advantages since it would be implemented in Rust. On Sat, Jan 11, 2014 at 2:03 PM, james ja...@mansionfamily.plus.com wrote: On 10/01/2014 08:54, Jan Niklas Hasse wrote: Also cmake still depends on make (or even worse Visual Studio / Xcode). We use cmake with ninja at work, and that seems to work pretty well. I suggest if you want to write a tool, then you first write something that generates ninja files. Then you immediately have a bootstrap mechanism, plus something that will do builds rather quickly thereafter. scons can be (very) slow. My experience with waf was better, but I think generating a nnja script is superior and there are several tools to do that. You could look at gyp, for example. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. Le 10 janv. 2014 08:43, Carter Schonwald carter.schonw...@gmail.com a écrit : If the in rust approach is chosen, I warmly recommend checking out some of the design ideas in Shake. Shake has a pretty nice design that allows for dynamic build deps (in make systems the way around that is to use make to make your make files), and a few other neat ideas, including but not limited to playing nice with ninja files (which I believe cmake can generate too). http://community.haskell.org/~ndm/shake/ http://hackage.haskell.org/package/shake On Friday, January 10, 2014, George Makrydakis wrote: Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon enough. G. Corey Richardson co...@octayn.net wrote: Hey all, The build system has grown a fair bit of complexity, and is getting hard to understand. I've been thinking about what could replace it moving forward. Most of the complexity stems from having to self-host (ie, staging) and cross compilation (which target are we compiling for, and with which host?) [...] 3. Write a build system in Rust. This would take care of everything for us, using ourselves. We'd have a small script fetch the snapshot and build the build system, and then hand off the rest of the build to it. This has the advantage of one less build-time dependency, but the disadvantage that it's going to be a lot of work. This could also potentially output tup, ninja[3], or another form of build script after taking configuration options and so-forth. It could also integrate with librustc for smart handling of comments-or-test-only changes, an issue near to my heart[4]. This build system could potentially be rustpkg, but as I understand it the current idea is to *remove* rustpkg's ability as a build system and keep it as a package manager. (At least, that is what I've understood of recent discussion; this could be wrong.) [...] ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
On 10/01/14 08:16, Gaetan wrote: I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. I'd agree with that on both counts: the principle of using something standard, and the two recommendations. CMake would probably get my vote, because it's not so much a build tool, as a meta tool for whichever system you prefer, so it would fit in well with various platform-specific IDEs, unusual platforms (android, embedded, ...), etc. That said, scons is also a strong contender, and which of the two is more open to integrating patches and working with new languages is very much worth considering. I think Rust will be contributing to the wider community by lending its support (and patches) to a common, modern build system, AND it will get something back in terms of users who already know the build system. On Friday, January 10, 2014, George Makrydakis wrote: Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon enough. Bear in mind that Debian are having a lot of issues packaging Rust already, because it self-compiles. If the build tool also had a Rust pre-dependency, that would be a big step backwards. -- Lee ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
Have you heart about waf? http://code.google.com/p/waf/ It only depends on Python so this would not result in another dependency. The python script ( 200 kB) can be included in the repository. I am all for using rustpkg though. And I'm strongly against cmake, because I don't know its language and don't like a build system which doesn't use an already existing one (like scons is using Python). Also cmake still depends on make (or even worse Visual Studio / Xcode). 2014/1/10 Corey Richardson co...@octayn.net Hey all, The build system has grown a fair bit of complexity, and is getting hard to understand. I've been thinking about what could replace it moving forward. Most of the complexity stems from having to self-host (ie, staging) and cross compilation (which target are we compiling for, and with which host?) Our build system must: 1. Work on all the platforms we support 2. Be able to track dependencies. Our ideal build system should: 1. Require minimal build-time dependencies 2. Allow ease of staging and cross compilation 3. Be easy to extend as we grow 4. Have readable build scripts 5. Have advanced configuration ability (NO_REBUILD, NO_BENCH, etc should all be retained) There are a few options: 1. Rework the current makefiles to be nicer. I'm not sure if this is feasible. Some stuff certainly could be easier, but the inherent problems of make (nested evals + calls, no named parameters (what does $(1) mean here, etc), general ugliness) make this unlikely to be a worthwhile effort, besides factoring out some of the current boilerplate. 2. Use a different build system. The major option here seems to be cmake[1], although I've heard murmurings of tup[2] and some other obscure things. I'm unsure tup is going to be of much help here. With our compilation model, fine-grained file-based dependencies are not very useful. However, it's awesome bottom-up dependency model could be neat. It's possible that we could use it with a combination of: 3. Write a build system in Rust. This would take care of everything for us, using ourselves. We'd have a small script fetch the snapshot and build the build system, and then hand off the rest of the build to it. This has the advantage of one less build-time dependency, but the disadvantage that it's going to be a lot of work. This could also potentially output tup, ninja[3], or another form of build script after taking configuration options and so-forth. It could also integrate with librustc for smart handling of comments-or-test-only changes, an issue near to my heart[4]. This build system could potentially be rustpkg, but as I understand it the current idea is to *remove* rustpkg's ability as a build system and keep it as a package manager. (At least, that is what I've understood of recent discussion; this could be wrong.) 4. Write a build system in $LANG. Python seems to be a good choice here, since we already depend on it for fetching the snapshot etc. This still has the disadvantage of being a lot of work, but would perhaps be easier than writing a build system in Rust. We would definitely lose hacker points for doing so. There are undoubtedly other options as well. Does anyone have good ideas or opinions on what we should do? Personally I think that 3 is going to be the best option, unless there's some super amazing build system I haven't heard of it. Which is totally possible! [1]: http://www.cmake.org/ [2]: http://gittup.org/tup/ [3]: http://martine.github.io/ninja/ [4]: https://github.com/mozilla/rust/issues/6522 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
See this page that compares scons to other build system: http://www.scons.org/wiki/SconsVsOtherBuildTools I still personally recommend CMake. One of the major feature is that it is NOT a build system, it a script factory that generates system dependant build file: Makefile for GNU, Visual Studio for Windows, Eclipse projects,... It actually replaces all bash scripts we usually write on large projects to trigger the builds. - Gaetan 2014/1/10 Jan Niklas Hasse jha...@gmail.com Have you heart about waf? http://code.google.com/p/waf/ It only depends on Python so this would not result in another dependency. The python script ( 200 kB) can be included in the repository. I am all for using rustpkg though. And I'm strongly against cmake, because I don't know its language and don't like a build system which doesn't use an already existing one (like scons is using Python). Also cmake still depends on make (or even worse Visual Studio / Xcode). 2014/1/10 Corey Richardson co...@octayn.net Hey all, The build system has grown a fair bit of complexity, and is getting hard to understand. I've been thinking about what could replace it moving forward. Most of the complexity stems from having to self-host (ie, staging) and cross compilation (which target are we compiling for, and with which host?) Our build system must: 1. Work on all the platforms we support 2. Be able to track dependencies. Our ideal build system should: 1. Require minimal build-time dependencies 2. Allow ease of staging and cross compilation 3. Be easy to extend as we grow 4. Have readable build scripts 5. Have advanced configuration ability (NO_REBUILD, NO_BENCH, etc should all be retained) There are a few options: 1. Rework the current makefiles to be nicer. I'm not sure if this is feasible. Some stuff certainly could be easier, but the inherent problems of make (nested evals + calls, no named parameters (what does $(1) mean here, etc), general ugliness) make this unlikely to be a worthwhile effort, besides factoring out some of the current boilerplate. 2. Use a different build system. The major option here seems to be cmake[1], although I've heard murmurings of tup[2] and some other obscure things. I'm unsure tup is going to be of much help here. With our compilation model, fine-grained file-based dependencies are not very useful. However, it's awesome bottom-up dependency model could be neat. It's possible that we could use it with a combination of: 3. Write a build system in Rust. This would take care of everything for us, using ourselves. We'd have a small script fetch the snapshot and build the build system, and then hand off the rest of the build to it. This has the advantage of one less build-time dependency, but the disadvantage that it's going to be a lot of work. This could also potentially output tup, ninja[3], or another form of build script after taking configuration options and so-forth. It could also integrate with librustc for smart handling of comments-or-test-only changes, an issue near to my heart[4]. This build system could potentially be rustpkg, but as I understand it the current idea is to *remove* rustpkg's ability as a build system and keep it as a package manager. (At least, that is what I've understood of recent discussion; this could be wrong.) 4. Write a build system in $LANG. Python seems to be a good choice here, since we already depend on it for fetching the snapshot etc. This still has the disadvantage of being a lot of work, but would perhaps be easier than writing a build system in Rust. We would definitely lose hacker points for doing so. There are undoubtedly other options as well. Does anyone have good ideas or opinions on what we should do? Personally I think that 3 is going to be the best option, unless there's some super amazing build system I haven't heard of it. Which is totally possible! [1]: http://www.cmake.org/ [2]: http://gittup.org/tup/ [3]: http://martine.github.io/ninja/ [4]: https://github.com/mozilla/rust/issues/6522 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
Hello, CMake does have a few things going for it: - It is a popular choice for C++ projects, including LLVM, WebKit and others, so this would provide familiarity from developers coming from C++ - As mentioned, it is a meta-build system which can generate project files for Xcode, Visual Studio, Ninja and others. This is very useful for cross-platform development - It has a good and sizable ecosystem (full time active maintainers, documentation, user questions on StackOverflow etc.) - It has a large collection of modules to find packages, detect compiler versions etc. Downsides for CMake include: - The built script language is primitive and not a familiar language like Python. It is easy enough to use for writing a build project file but for more complex logic, I've found it easier to write separate commands in Python/Ruby which CMake then invokes. - CMakeLists.txt files are not declarative documents that can be easily parsed by other tools for eg. IDE integration. Having said that, the CMake developers are aware of the benefits of more declarative ways of specifying things and there is a general trend in that direction. - Adds a non-rusty dependency to rust. Regards, Rob. On 10 January 2014 10:06, Gaetan gae...@xeberon.net wrote: See this page that compares scons to other build system: http://www.scons.org/wiki/SconsVsOtherBuildTools I still personally recommend CMake. One of the major feature is that it is NOT a build system, it a script factory that generates system dependant build file: Makefile for GNU, Visual Studio for Windows, Eclipse projects,... It actually replaces all bash scripts we usually write on large projects to trigger the builds. - Gaetan 2014/1/10 Jan Niklas Hasse jha...@gmail.com Have you heart about waf? http://code.google.com/p/waf/ It only depends on Python so this would not result in another dependency. The python script ( 200 kB) can be included in the repository. I am all for using rustpkg though. And I'm strongly against cmake, because I don't know its language and don't like a build system which doesn't use an already existing one (like scons is using Python). Also cmake still depends on make (or even worse Visual Studio / Xcode). 2014/1/10 Corey Richardson co...@octayn.net Hey all, The build system has grown a fair bit of complexity, and is getting hard to understand. I've been thinking about what could replace it moving forward. Most of the complexity stems from having to self-host (ie, staging) and cross compilation (which target are we compiling for, and with which host?) Our build system must: 1. Work on all the platforms we support 2. Be able to track dependencies. Our ideal build system should: 1. Require minimal build-time dependencies 2. Allow ease of staging and cross compilation 3. Be easy to extend as we grow 4. Have readable build scripts 5. Have advanced configuration ability (NO_REBUILD, NO_BENCH, etc should all be retained) There are a few options: 1. Rework the current makefiles to be nicer. I'm not sure if this is feasible. Some stuff certainly could be easier, but the inherent problems of make (nested evals + calls, no named parameters (what does $(1) mean here, etc), general ugliness) make this unlikely to be a worthwhile effort, besides factoring out some of the current boilerplate. 2. Use a different build system. The major option here seems to be cmake[1], although I've heard murmurings of tup[2] and some other obscure things. I'm unsure tup is going to be of much help here. With our compilation model, fine-grained file-based dependencies are not very useful. However, it's awesome bottom-up dependency model could be neat. It's possible that we could use it with a combination of: 3. Write a build system in Rust. This would take care of everything for us, using ourselves. We'd have a small script fetch the snapshot and build the build system, and then hand off the rest of the build to it. This has the advantage of one less build-time dependency, but the disadvantage that it's going to be a lot of work. This could also potentially output tup, ninja[3], or another form of build script after taking configuration options and so-forth. It could also integrate with librustc for smart handling of comments-or-test-only changes, an issue near to my heart[4]. This build system could potentially be rustpkg, but as I understand it the current idea is to *remove* rustpkg's ability as a build system and keep it as a package manager. (At least, that is what I've understood of recent discussion; this could be wrong.) 4. Write a build system in $LANG. Python seems to be a good choice here, since we already depend on it for fetching the snapshot etc. This still has the disadvantage of being a lot of work, but would perhaps be easier than writing a build system in Rust. We would definitely lose hacker points for doing so. There are undoubtedly other options as well. Does
Re: [rust-dev] RFC: Future of the Build System
A further point in favour of CMake is that it would make multi-language projects easier to manage, in particular transitioning a C-family project to Rust. On Friday 10 January 2014 08:34:32 Lee Braiden wrote: On 10/01/14 08:16, Gaetan wrote: I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. I'd agree with that on both counts: the principle of using something standard, and the two recommendations. CMake would probably get my vote, because it's not so much a build tool, as a meta tool for whichever system you prefer, so it would fit in well with various platform-specific IDEs, unusual platforms (android, embedded, ...), etc. That said, scons is also a strong contender, and which of the two is more open to integrating patches and working with new languages is very much worth considering. I think Rust will be contributing to the wider community by lending its support (and patches) to a common, modern build system, AND it will get something back in terms of users who already know the build system. On Friday, January 10, 2014, George Makrydakis wrote: Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon enough. Bear in mind that Debian are having a lot of issues packaging Rust already, because it self-compiles. If the build tool also had a Rust pre-dependency, that would be a big step backwards. signature.asc Description: This is a digitally signed message part. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
This RFC isn't about using a single build system for everything, it's the build system we use to build Rust itself. On Fri, Jan 10, 2014 at 10:06 AM, Diggory Hardy li...@dhardy.name wrote: A further point in favour of CMake is that it would make multi-language projects easier to manage, in particular transitioning a C-family project to Rust. On Friday 10 January 2014 08:34:32 Lee Braiden wrote: On 10/01/14 08:16, Gaetan wrote: I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. I'd agree with that on both counts: the principle of using something standard, and the two recommendations. CMake would probably get my vote, because it's not so much a build tool, as a meta tool for whichever system you prefer, so it would fit in well with various platform-specific IDEs, unusual platforms (android, embedded, ...), etc. That said, scons is also a strong contender, and which of the two is more open to integrating patches and working with new languages is very much worth considering. I think Rust will be contributing to the wider community by lending its support (and patches) to a common, modern build system, AND it will get something back in terms of users who already know the build system. On Friday, January 10, 2014, George Makrydakis wrote: Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon enough. Bear in mind that Debian are having a lot of issues packaging Rust already, because it self-compiles. If the build tool also had a Rust pre-dependency, that would be a big step backwards. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
On 01/10/2014 06:19 AM, Robert Knight wrote: Hello, CMake does have a few things going for it: One more consideration is that LLVM can be built with CMake afaik, so if we switch to CMake we may be able to drop the autotools dependency, which is a more annoying dependency to fulfill (on Windows) than CMake (I don't know if Rust has other components that require autotools though). Along the same lines, we also require Python for whatever reason, so SCons would be a natural option too (it can't build LLVM though). I'd only use SCons conditional on it accepting a Rust dependency scanner into its source: using its current custom scanner infrastructure is not practical as I found out. As for waf... they and Debian have been having a tiff (e.g. see http://waf-devel.blogspot.com/2012/01/debian.html , https://lists.debian.org/debian-devel/2012/02/msg00207.html ). I would not suggest it based on that. -SL ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
I also agree that the way waf works is quite weird to use, but this is actually how most of the installers works under windows or some on MacOS: the code of the installers is embedded into the distributed package. This violates the debian packaging rules, and I think this will be the same with rust. I however really like this approach. You don't have a huge among of dependencies to setup in order to build your package. This is not a problem on debian where apt does to marveillous job, but on Windows/Mac/generic linux/arm, .. this is a nightmare. One more point in favor of CMake to build rust: you can build android/arm/misc (thanks to Makefile) with the same CMakeList.txt files, or with external module inclusion. I also agree that its syntax used to be quite ugly (the famous if() / else() / endif()), but not so much in the lastest versions... But if you require python for building, scons is the perfect, natural candidate. - Gaetan 2014/1/10 SiegeLord slab...@aim.com On 01/10/2014 06:19 AM, Robert Knight wrote: Hello, CMake does have a few things going for it: One more consideration is that LLVM can be built with CMake afaik, so if we switch to CMake we may be able to drop the autotools dependency, which is a more annoying dependency to fulfill (on Windows) than CMake (I don't know if Rust has other components that require autotools though). Along the same lines, we also require Python for whatever reason, so SCons would be a natural option too (it can't build LLVM though). I'd only use SCons conditional on it accepting a Rust dependency scanner into its source: using its current custom scanner infrastructure is not practical as I found out. As for waf... they and Debian have been having a tiff (e.g. see http://waf-devel.blogspot.com/2012/01/debian.html , https://lists.debian.org/debian-devel/2012/02/msg00207.html ). I would not suggest it based on that. -SL ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
2014/1/10 Robert Knight robertkni...@gmail.com Hello, CMake does have a few things going for it: - It is a popular choice for C++ projects, including LLVM, WebKit and others, so this would provide familiarity from developers coming from C++ Same for scons (Blender, MongoDB) and waf (Samba, node.js). - As mentioned, it is a meta-build system which can generate project files for Xcode, Visual Studio, Ninja and others. This is very useful for cross-platform development I don't think this is useful for Rust itself as these IDEs don't support Rust anyway and some things won't work (like copying files around which is currently done in the Makefiles and seems to be hard if not impossible to do in VC++/Xcode to me). Some counter arguments for cmake (I haven't worked with many cmake projects though, so these points are just my personal opinion, sorry if I'm spreading FUD): - Some projects [1] include handcrafted VC++ and Xcode project files anyway, even if using cmake. Looks to me like cmake's generator isn't worth it. - To create Makefiles for MinGW you have to use `cmake -G MinGW Makefiles` which I find rather ugly looking (I always have to look it up). - CMakeLists.txt often look ugly [2] and don't follow any particular style (lower case vs. upper case, etc.). - Using cmake on Windows wasn't as pleasant as scons or autotools (when working with msys or cmd.exe and not Visual Studio). I have to admit ccmake is nice though! [1] https://github.com/slembcke/Chipmunk2D [2] https://github.com/rougier/freetype-gl/blob/master/CMakeLists.txt ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
Best Reason ever for a Rust Build System = You Prove Rust Itself. So get hacking on a Rust Build System. -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
- CMakeLists.txt often look ugly [2] and don't follow any particular style (lower case vs. upper case, etc.). A fair point, though a number of projects do have coding conventions for CMakeLists.txt files, one of which could be adopted - eg. http://techbase.kde.org/Policies/CMake_Coding_Style Regards, Rob. On 10 January 2014 17:38, Thad Guidry thadgui...@gmail.com wrote: Best Reason ever for a Rust Build System = You Prove Rust Itself. So get hacking on a Rust Build System. -- -Thad +ThadGuidry Thad on LinkedIn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
On Fri, Jan 10, 2014 at 3:34 AM, Lee Braiden leebr...@gmail.com wrote: On 10/01/14 08:16, Gaetan wrote: Bear in mind that Debian are having a lot of issues packaging Rust already, because it self-compiles. If the build tool also had a Rust pre-dependency, that would be a big step backwards. What kind of issues? I've had close to zero issues maintaining a package in the Arch repositories along with a nightly build. The only difficulty has been the occasionally Makefile race with `-j8`. It would be nice if it wasn't necessary to strip rpaths with chrpath too... ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
Lee, Can you go into more detail on the problems that Debian is having packaging Rust? This sounds like a classic bootstrapping problem, and I'm sure other languages are running into it. How does Debian handle that first build of `make` or `bash` that I assume gcc depends on? On Fri, Jan 10, 2014 at 12:34 AM, Lee Braiden leebr...@gmail.com wrote: On 10/01/14 08:16, Gaetan wrote: I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. I'd agree with that on both counts: the principle of using something standard, and the two recommendations. CMake would probably get my vote, because it's not so much a build tool, as a meta tool for whichever system you prefer, so it would fit in well with various platform-specific IDEs, unusual platforms (android, embedded, ...), etc. That said, scons is also a strong contender, and which of the two is more open to integrating patches and working with new languages is very much worth considering. I think Rust will be contributing to the wider community by lending its support (and patches) to a common, modern build system, AND it will get something back in terms of users who already know the build system. On Friday, January 10, 2014, George Makrydakis wrote: Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon enough. Bear in mind that Debian are having a lot of issues packaging Rust already, because it self-compiles. If the build tool also had a Rust pre-dependency, that would be a big step backwards. -- Lee ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
I definitely encourage any sort of experimentation with build systems in Rust. But the most important criterion for Rust to adopt a build system in practice is going to be whether someone is available and willing to maintain it at a production quality level. That trumps all technical and language evangelism issues, in my mind. Not saying we don't have the resources in the community, mind you, just establishing what is in my mind an important criterion. Patrick Thad Guidry thadgui...@gmail.com wrote: Best Reason ever for a Rust Build System = You Prove Rust Itself. So get hacking on a Rust Build System. -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
I think we are going to end up doing a total rewrite. Here are my current concerns: * We need to make a big change to the way bootstrapping works in order to cross-compile correctly: https://github.com/mozilla/rust/issues/11145 * Adding new crates to the current build system is very error-prone. We need all the logic for building them to be encapsulated into something simple. * The build system that Rust uses should be the build system we are promoting as the defacto community build system, and as such it also needs to integrate with rustpkg. My personal preference is to create a tool that can eventually integrate into rustpkg that generates ninja scripts, and package and distribute ninja ourselves (as rust-ninja or something). On 01/09/2014 09:46 PM, Corey Richardson wrote: Hey all, The build system has grown a fair bit of complexity, and is getting hard to understand. I've been thinking about what could replace it moving forward. Most of the complexity stems from having to self-host (ie, staging) and cross compilation (which target are we compiling for, and with which host?) Our build system must: 1. Work on all the platforms we support 2. Be able to track dependencies. Our ideal build system should: 1. Require minimal build-time dependencies 2. Allow ease of staging and cross compilation 3. Be easy to extend as we grow 4. Have readable build scripts 5. Have advanced configuration ability (NO_REBUILD, NO_BENCH, etc should all be retained) There are a few options: 1. Rework the current makefiles to be nicer. I'm not sure if this is feasible. Some stuff certainly could be easier, but the inherent problems of make (nested evals + calls, no named parameters (what does $(1) mean here, etc), general ugliness) make this unlikely to be a worthwhile effort, besides factoring out some of the current boilerplate. 2. Use a different build system. The major option here seems to be cmake[1], although I've heard murmurings of tup[2] and some other obscure things. I'm unsure tup is going to be of much help here. With our compilation model, fine-grained file-based dependencies are not very useful. However, it's awesome bottom-up dependency model could be neat. It's possible that we could use it with a combination of: 3. Write a build system in Rust. This would take care of everything for us, using ourselves. We'd have a small script fetch the snapshot and build the build system, and then hand off the rest of the build to it. This has the advantage of one less build-time dependency, but the disadvantage that it's going to be a lot of work. This could also potentially output tup, ninja[3], or another form of build script after taking configuration options and so-forth. It could also integrate with librustc for smart handling of comments-or-test-only changes, an issue near to my heart[4]. This build system could potentially be rustpkg, but as I understand it the current idea is to *remove* rustpkg's ability as a build system and keep it as a package manager. (At least, that is what I've understood of recent discussion; this could be wrong.) 4. Write a build system in $LANG. Python seems to be a good choice here, since we already depend on it for fetching the snapshot etc. This still has the disadvantage of being a lot of work, but would perhaps be easier than writing a build system in Rust. We would definitely lose hacker points for doing so. There are undoubtedly other options as well. Does anyone have good ideas or opinions on what we should do? Personally I think that 3 is going to be the best option, unless there's some super amazing build system I haven't heard of it. Which is totally possible! [1]: http://www.cmake.org/ [2]: http://gittup.org/tup/ [3]: http://martine.github.io/ninja/ [4]: https://github.com/mozilla/rust/issues/6522 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
Hmm, after further reading, I think I've they're making more progress on it than I thought, from first impressions of the discussion. They've had a lot of different issues to deal with, not just the self-dependency, but they got 0.7 packaged, at least. More detail here, particularly in the last comment: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689207 You can see there that the debian packagers also referenced a list of issues that the fedora wrote up: https://github.com/mozilla/rust/wiki/Note-packaging -- Lee On 10/01/14 18:43, Erick Tryzelaar wrote: Lee, Can you go into more detail on the problems that Debian is having packaging Rust? This sounds like a classic bootstrapping problem, and I'm sure other languages are running into it. How does Debian handle that first build of `make` or `bash` that I assume gcc depends on? On Fri, Jan 10, 2014 at 12:34 AM, Lee Braiden leebr...@gmail.com mailto:leebr...@gmail.com wrote: On 10/01/14 08:16, Gaetan wrote: I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. I'd agree with that on both counts: the principle of using something standard, and the two recommendations. CMake would probably get my vote, because it's not so much a build tool, as a meta tool for whichever system you prefer, so it would fit in well with various platform-specific IDEs, unusual platforms (android, embedded, ...), etc. That said, scons is also a strong contender, and which of the two is more open to integrating patches and working with new languages is very much worth considering. I think Rust will be contributing to the wider community by lending its support (and patches) to a common, modern build system, AND it will get something back in terms of users who already know the build system. On Friday, January 10, 2014, George Makrydakis wrote: Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon enough. Bear in mind that Debian are having a lot of issues packaging Rust already, because it self-compiles. If the build tool also had a Rust pre-dependency, that would be a big step backwards. -- Lee ___ Rust-dev mailing list Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
On 01/10/2014 04:08 PM, Corey Richardson wrote: This RFC isn't about using a single build system for everything, it's the build system we use to build Rust itself. On Fri, Jan 10, 2014 at 10:06 AM, Diggory Hardy li...@dhardy.name wrote: A further point in favour of CMake is that it would make multi-language projects easier to manage, in particular transitioning a C-family project to Rust. On Friday 10 January 2014 08:34:32 Lee Braiden wrote: Both Rust and Servo are multi-language projects, and LLVM already uses CMake. Wouldn't it be a plus to bootstrap Rust with the Standard Rust Build System(tm)? Also, CMake can use the Visual Studio toolchain on Windows. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
I'm all for CMake. Not so much for the technical merits, but the amount of infrastructure already built up around it. KDE has adopted it wholesale, meaning all the dependencies of the entire KDE project are supported out of the box, and also IDE support in KDevelop, Qt Creator, emacs/vi etc. Bootstrapping comes to mind as a potential problem, but LLVM and Clang use it too. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
There is little reason to believe that having a build system in Rust would make It harder for people to package. I do understand the predependecy argument, but the Rust compiler itself in order to compile has predependencies anyway, as does any similar project. Therefore the decisional weight of choosing a non - rust based solution over a rust one because Debian packagers have problems packaging a compiler is not adequately justified. Using a well known build system as a means to appeal to programmers is seemingly an advantage, but it does not exonerate them from having to be competent in Rust before they write useful programs. And that has a learning curve superior to that of a build system. As for boost's jam I have nothing to say other than boost having its own build system makes it easy for boost first; this does not mean that their needs are those of everybody else and boost is a library, not a programming language itself. So, again, a decision based on picking a popular solution on the basis of such a comparison, has flawed background. Lastly, imagine the irony of Rust proposing to use python, c, c++ based build tools for simple packages. That would make packagers more frustrated because of a wider set of dependecies. While end users would have to also deal with a known system, its eventual inadequacies could not be met directly by Rust devs unless they start amending that system in order to deal with them. Therefore, maintenance overhead is inescapable either way, with the pessimization of relying in another nom - Rust project in order to make it worth your while to enjoy programming in Rust. The only valid argument against having a build system proposed as the official, defacto, cross - platform way of building rust packages written in rust is its development and maintenance overhead for the rust core team itself. That problem is easily circumvented by not proposing one right now and letting it to the end developer decide. If however an official build system is to be proposed, Rust developers merit having it done on their own platform, thus proving rust's worth. It is 2014 after all. G. Lee Braiden leebr...@gmail.com wrote: On 10/01/14 08:16, Gaetan wrote: I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. I'd agree with that on both counts: the principle of using something standard, and the two recommendations. CMake would probably get my vote, because it's not so much a build tool, as a meta tool for whichever system you prefer, so it would fit in well with various platform-specific IDEs, unusual platforms (android, embedded, ...), etc. That said, scons is also a strong contender, and which of the two is more open to integrating patches and working with new languages is very much worth considering. I think Rust will be contributing to the wider community by lending its support (and patches) to a common, modern build system, AND it will get something back in terms of users who already know the build system. On Friday, January 10, 2014, George Makrydakis wrote: Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon enough. Bear in mind that Debian are having a lot of issues packaging Rust already, because it self-compiles. If the build tool also had a Rust pre-dependency, that would be a big step backwards. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon enough. G. Corey Richardson co...@octayn.net wrote: Hey all, The build system has grown a fair bit of complexity, and is getting hard to understand. I've been thinking about what could replace it moving forward. Most of the complexity stems from having to self-host (ie, staging) and cross compilation (which target are we compiling for, and with which host?) [...] 3. Write a build system in Rust. This would take care of everything for us, using ourselves. We'd have a small script fetch the snapshot and build the build system, and then hand off the rest of the build to it. This has the advantage of one less build-time dependency, but the disadvantage that it's going to be a lot of work. This could also potentially output tup, ninja[3], or another form of build script after taking configuration options and so-forth. It could also integrate with librustc for smart handling of comments-or-test-only changes, an issue near to my heart[4]. This build system could potentially be rustpkg, but as I understand it the current idea is to *remove* rustpkg's ability as a build system and keep it as a package manager. (At least, that is what I've understood of recent discussion; this could be wrong.) [...] ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
