Discussion:
RFC: Future of the Build System
(too old to reply)
Corey Richardson
2014-01-10 05:46:43 UTC
Permalink
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
George Makrydakis
2014-01-10 06:46:07 UTC
Permalink
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.
Post by Corey Richardson
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?)
[...]
Post by Corey Richardson
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.)
[...]
Carter Schonwald
2014-01-10 07:43:17 UTC
Permalink
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
Post by George Makrydakis
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.
Post by Corey Richardson
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?)
[...]
Post by Corey Richardson
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/795a2095/attachment.html>
Gaetan
2014-01-10 08:16:49 UTC
Permalink
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.schonwald at gmail.com> a
Post by Carter Schonwald
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
Post by George Makrydakis
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.
Post by Corey Richardson
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?)
[...]
Post by Corey Richardson
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/983be2ae/attachment.html>
Lee Braiden
2014-01-10 08:34:32 UTC
Permalink
Post by Gaetan
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.
Post by Gaetan
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/86d0a549/attachment-0001.html>
Diggory Hardy
2014-01-10 15:06:01 UTC
Permalink
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.
Post by Lee Braiden
Post by Gaetan
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.
Post by Gaetan
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/3d1ca79d/attachment.sig>
Corey Richardson
2014-01-10 15:08:09 UTC
Permalink
This RFC isn't about using a single build system for everything, it's
the build system we use to build Rust itself.
Post by Diggory Hardy
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.
Post by Lee Braiden
Post by Gaetan
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.
Post by Gaetan
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
György Andrasek
2014-01-10 20:39:47 UTC
Permalink
Post by Corey Richardson
This RFC isn't about using a single build system for everything, it's
the build system we use to build Rust itself.
Post by Diggory Hardy
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.
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.
Daniel Micay
2014-01-10 18:27:11 UTC
Permalink
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...
Erick Tryzelaar
2014-01-10 18:43:43 UTC
Permalink
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?
Post by Gaetan
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.
Post by George Makrydakis
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/8433b080/attachment.html>
Lee Braiden
2014-01-10 19:18:32 UTC
Permalink
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
Post by Erick Tryzelaar
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 <leebraid at gmail.com
Post by Gaetan
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.
Post by Gaetan
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 at mozilla.org <mailto:Rust-dev at mozilla.org>
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/336380e1/attachment.html>
George Makrydakis
2014-01-11 07:56:46 UTC
Permalink
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.
Post by Lee Braiden
Post by Gaetan
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.
Post by Gaetan
Hello,
Having a build system entirely dependent of Rust alone, would
make the entire experience in deploying the language
extremely
Post by Gaetan
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.
Michael Neumann
2014-01-11 10:42:21 UTC
Permalink
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
Post by 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.
Post by Lee Braiden
Post by Gaetan
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.
Post by Gaetan
Hello,
Having a build system entirely dependent of Rust alone, would
make the entire experience in deploying the language
extremely
Post by Gaetan
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
George Makrydakis
2014-01-11 11:26:23 UTC
Permalink
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.
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
Post by George Makrydakis
There is little reason to believe that having a build system in Rust
would make It harder for people to package.
Post by George Makrydakis
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.
Post by George Makrydakis
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.
Post by George Makrydakis
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.
Post by George Makrydakis
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.
Post by George Makrydakis
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.
Post by George Makrydakis
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.
Post by George Makrydakis
G.
Post by Lee Braiden
Post by Gaetan
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
Post by George Makrydakis
Post by Lee Braiden
Post by Gaetan
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
Post by George Makrydakis
Post by Lee Braiden
Post by Gaetan
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
Post by George Makrydakis
Post by Lee Braiden
with various platform-specific IDEs, unusual platforms (android,
embedded, ...), etc. That said, scons is also a strong contender,
and
Post by George Makrydakis
Post by Lee Braiden
which of the two is more open to integrating patches and working
with
Post by George Makrydakis
Post by Lee Braiden
new languages is very much worth considering.
I think Rust will be contributing to the wider community by lending
its
Post by George Makrydakis
Post by Lee Braiden
support (and patches) to a common, modern build system, AND it will
get
Post by George Makrydakis
Post by Lee Braiden
something back in terms of users who already know the build system.
Post by Gaetan
Hello,
Having a build system entirely dependent of Rust alone,
would
Post by George Makrydakis
Post by Lee Braiden
Post by Gaetan
make the entire experience in deploying the language
extremely
Post by Gaetan
cohere. The only counter - argument is indeed that it
would
Post by George Makrydakis
Post by Lee Braiden
Post by Gaetan
require some work to get this to fruition. I would like to
know if this has any chance of getting priority soon
enough.
Post by George Makrydakis
Post by Lee Braiden
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
Post by George Makrydakis
Post by Lee Braiden
pre-dependency, that would be a big step backwards.
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140111/d5d5c3c4/attachment-0001.html>
james
2014-01-11 11:59:59 UTC
Permalink
Post by George Makrydakis
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.
George Makrydakis
2014-01-11 17:08:56 UTC
Permalink
Which is why the argument of easier packaging because tool X is used by
person Y advocating it, is meaningless from both a theoretical and
practical point of view. In the end, it is just an application of graph
theory, which is widely used in dependency resolution. Another option would
be a sat solver producing the same result as for example is the case for
libzypp in openSuSE.

Again, it is a matter of combining any of these solutions with a reliable
and simple to understand format in order to produce a build system that is
consistent first, fool - proof most of the time. Surely, doing this in Rust
should be quite easily doable, given the fact that it is designed to be a
systems language. Handling entire package life cycles would be a natural
fit for a language with Rust's problem domain, even beyond the purposes of
Rust itself. Think big, then bigger.

G.
Post by james
Post by George Makrydakis
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140111/30993623/attachment.html>
Gaetan
2014-01-13 13:46:20 UTC
Permalink
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 <irrequietus at gmail.com>
Post by 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.
Post by Lee Braiden
Post by Gaetan
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.
Post by Gaetan
Hello,
Having a build system entirely dependent of Rust alone, would
make the entire experience in deploying the language
extremely
Post by Gaetan
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140113/933880ac/attachment-0001.html>
George Makrydakis
2014-01-13 15:30:22 UTC
Permalink
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.
Post by Gaetan
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 <irrequietus at gmail.com>
Post by George Makrydakis
There is little reason to believe that having a build system in Rust
would
Post by George Makrydakis
make It harder for people to package.
I do understand the predependecy argument, but the Rust compiler
itself in
Post by George Makrydakis
order to compile has predependencies anyway, as does any similar
project.
Post by George Makrydakis
Therefore the decisional weight of choosing a non - rust based
solution
Post by George Makrydakis
over a rust one because Debian packagers have problems packaging a
compiler
Post by George Makrydakis
is not adequately justified.
Using a well known build system as a means to appeal to programmers
is
Post by George Makrydakis
seemingly an advantage, but it does not exonerate them from having to
be
Post by George Makrydakis
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
Post by George Makrydakis
build system makes it easy for boost first; this does not mean that
their
Post by George Makrydakis
needs are those of everybody else and boost is a library, not a
programming
Post by George Makrydakis
language itself. So, again, a decision based on picking a popular
solution
Post by George Makrydakis
on the basis of such a comparison, has flawed background.
Lastly, imagine the irony of Rust proposing to use python, c, c++
based
Post by George Makrydakis
build tools for simple packages. That would make packagers more
frustrated
Post by George Makrydakis
because of a wider set of dependecies. While end users would have to
also
Post by George Makrydakis
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
Post by George Makrydakis
deal with them. Therefore, maintenance overhead is inescapable either
way,
Post by George Makrydakis
with the pessimization of relying in another nom - Rust project in
order to
Post by George Makrydakis
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
Post by George Makrydakis
in rust is its development and maintenance overhead for the rust core
team
Post by George Makrydakis
itself.
That problem is easily circumvented by not proposing one right now
and
Post by George Makrydakis
letting it to the end developer decide. If however an official build
system
Post by George Makrydakis
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.
Post by Lee Braiden
Post by Gaetan
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
Post by George Makrydakis
Post by Lee Braiden
Post by Gaetan
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
Post by George Makrydakis
Post by Lee Braiden
Post by Gaetan
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
Post by George Makrydakis
Post by Lee Braiden
with various platform-specific IDEs, unusual platforms (android,
embedded, ...), etc. That said, scons is also a strong contender,
and
Post by George Makrydakis
Post by Lee Braiden
which of the two is more open to integrating patches and working
with
Post by George Makrydakis
Post by Lee Braiden
new languages is very much worth considering.
I think Rust will be contributing to the wider community by lending
its
Post by George Makrydakis
Post by Lee Braiden
support (and patches) to a common, modern build system, AND it will
get
Post by George Makrydakis
Post by Lee Braiden
something back in terms of users who already know the build system.
Post by Gaetan
Hello,
Having a build system entirely dependent of Rust alone,
would
Post by George Makrydakis
Post by Lee Braiden
Post by Gaetan
make the entire experience in deploying the language
extremely
Post by Gaetan
cohere. The only counter - argument is indeed that it
would
Post by George Makrydakis
Post by Lee Braiden
Post by Gaetan
require some work to get this to fruition. I would like to
know if this has any chance of getting priority soon
enough.
Post by George Makrydakis
Post by Lee Braiden
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
Post by George Makrydakis
Post by Lee Braiden
pre-dependency, that would be a big step backwards.
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140113/46f3b005/attachment.html>
comex
2014-01-14 09:29:17 UTC
Permalink
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
Post by George Makrydakis
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.
Gaetan
2014-01-14 10:03:49 UTC
Permalink
Post by comex
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
Post by comex
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.
Post by comex
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/4246966e/attachment.html>
George Makrydakis
2014-01-14 16:22:58 UTC
Permalink
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.
Post by Gaetan
Post by comex
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
Post by comex
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.
Post by comex
most of the alternatives I know about are
at least slow, and often poorly maintained, insufficiently general,
et
Post by comex
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/46bf69d5/attachment-0001.html>
Gaetan
2014-01-14 16:28:49 UTC
Permalink
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 <irrequietus at gmail.com>
Post by George Makrydakis
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.
Post by comex
However, I'd say there is a stunning lack of existing build systems
Post by comex
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
Post by comex
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.
Post by comex
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/b5ef1549/attachment.html>
George Makrydakis
2014-01-14 20:17:06 UTC
Permalink
Already too much I guess.
Post by Gaetan
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 <irrequietus at gmail.com>
Post by George Makrydakis
Lack of manpower. Correct. As I have written elsewhere in these
threads,
Post by George Makrydakis
this is why an interim solution of a third party tool should perhaps
be
Post by George Makrydakis
choosen, instead of sactioning a build system in any language relic X
as
Post by George Makrydakis
the official tool.
Closer to 1.0, the need will become more apparent. I do not see a
task
Post by George Makrydakis
team / working group proposing this and in order for any official
guideline
Post by George Makrydakis
to be followed, this is a step to be taken. Wasn't this the purpose
of this
Post by George Makrydakis
thread?
Perhaps this is what comex is trying to say, albeit with his own
peculiar
Post by George Makrydakis
rhetorical structure - I doubt that anybody is "trolling", knowingly.
I
Post by George Makrydakis
still think that for the intended scope, Rust should just need Rust.
Post by comex
However, I'd say there is a stunning lack of existing build systems
Post by comex
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
Post by comex
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
Post by George Makrydakis
Post by comex
a import module.
Post by comex
most of the alternatives I know about are
at least slow, and often poorly maintained, insufficiently general,
et
Post by George Makrydakis
Post by comex
Post by comex
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
Post by George Makrydakis
Post by comex
Post by comex
than alone. So I'd personally like to see a new build system
regardless.
Post by George Makrydakis
Post by comex
I also agree that having a proper build system sounds sexy, however
do
Post by George Makrydakis
Post by comex
the rust dev team has enough man power for that?
Why not try to assemble a task that will evaluate several existing
build
Post by George Makrydakis
Post by comex
system instead of just trolling in this thread, to see exactly what
are the
Post by George Makrydakis
Post by comex
advantages and flaws of each candidates?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/197bcb73/attachment.html>
George Makrydakis
2014-01-14 16:09:55 UTC
Permalink
Rust is early in its lifecycle as a language and at a stage where useful applications implemented in it are about to break ground. Deciding on a build system without the multitude of pitfalls that affect curent status quo solutions is detrimental to the language now, not after it has established its own legacy.

Your argument can be generalized into language design. By analogy, we should all stick to what we know, depend on older languages and multitudes of dependencies because they work well.

If you consider Rust a systems language, surely you see how bizzare - if not somewhat ludicrous - it will sound for Rust to have an *official* (which this thread is all about) build system that needs language relic X to work.

You do conclude however in indeed wanting to see some new build system beyond the usual graph theory rehash. On that, we agree. Rust is capable of doing this just for Rust.
Post by comex
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
Post by George Makrydakis
Again, note that this rather long thread is about discussing in the
end what
Post by George Makrydakis
the official stance should be. There is no valid reason other than
lack of
Post by George Makrydakis
manpower and / or language immaturity for having to depend on ruby,
python,
Post by George Makrydakis
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/dbffb190/attachment.html>
Patrick Walton
2014-01-14 17:25:16 UTC
Permalink
Post by comex
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
Post by George Makrydakis
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
George Makrydakis
2014-01-14 20:24:20 UTC
Permalink
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.
Post by George Makrydakis
Post by comex
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
Post by George Makrydakis
Again, note that this rather long thread is about discussing in the
end what
Post by comex
Post by George Makrydakis
the official stance should be. There is no valid reason other than
lack of
Post by comex
Post by George Makrydakis
manpower and / or language immaturity for having to depend on ruby,
python,
Post by comex
Post by George Makrydakis
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
Post by comex
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/4bf1254d/attachment.html>
Lee Braiden
2014-01-14 20:43:36 UTC
Permalink
Post by Patrick Walton
Post by comex
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
Post by George Makrydakis
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<snip>
However, I'd say there is a stunning lack of existing build systems
that actually combine a clean design, flexibility, portability, and
performance<snip>
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": "Loading Image...",
"alt-text": "Features massive bugs",
},
},

"bug-tickets": "http://overloaded-cloud-system.buggysoft.com",

"authors": {
"author1": {
"email": "author1 at 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
George Makrydakis
2014-01-14 20:51:55 UTC
Permalink
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.
Post by Lee Braiden
Post by Patrick Walton
Post by comex
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
Post by George Makrydakis
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
Post by Patrick Walton
Post by comex
of each language community are really mostly identical<snip>
However, I'd say there is a stunning lack of existing build systems
that actually combine a clean design, flexibility, portability, and
performance<snip>
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": "author1 at 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",
"http://somehub.com/someuser/someotherproject/",
"min-git-tag": "04a453543",
"max-git-tag": "045ead634",
"http://someotherproject.com/somepath-${version}.tgz",
"distro-version-ok": "true"
}
},
"external-libs": {
"libssl": {
"min-version": "0.1",
"max-version": "0.1",
"http://somehub.com/someuser/someotherproject/",
"min-git-tag": "04a453543",
"max-git-tag": "045ead634",
"http://someotherproject.com/somepath-${version}.tgz"
"distro-version-ok": "true",
}
},
}
}
]
--
Lee
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/b6c4d8de/attachment-0001.html>
Lee Braiden
2014-01-14 22:11:19 UTC
Permalink
Post by George Makrydakis
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
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
Post by George Makrydakis
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
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<snip> However, I'd say there is a
stunning lack of existing build systems that actually
combine a clean design, flexibility, portability, and
performance<snip>
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": "author1 at 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": "0.1",
"max-version": "0.1",
"http://somehub.com/someuser/someotherproject/",
"min-git-tag": "04a453543",
"max-git-tag": "045ead634",
"http://someotherproject.com/somepath-${version}.tgz",
"distro-version-ok": "true"
}
},
"external-libs": {
"libssl": {
"min-version": "0.1",
"max-version": "0.1",
"http://somehub.com/someuser/someotherproject/",
"min-git-tag": "04a453543",
"max-git-tag": "045ead634",
"http://someotherproject.com/somepath-${version}.tgz"
"distro-version-ok": "true",
}
},
}
}
]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/8236f568/attachment.html>
Jan Niklas Hasse
2014-01-14 22:31:00 UTC
Permalink
Post by Lee Braiden
Post by George Makrydakis
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
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.
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.**
I don't understand what debian's package manager has to do with a build
system?

There's no reason why

apt-get install librust-sdl2-dev

shouldn't work, no matter what rust-sdl2 uses for building itself. The
package will just contain a rlib file and put it inside
/usr/lib/rustlib/<target-triple>/.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/1fbc02f1/attachment.html>
Lee Braiden
2014-01-14 22:41:20 UTC
Permalink
Post by Jan Niklas Hasse
I don't understand what debian's package manager has to do with a
build system?
There's no reason why
apt-get install librust-sdl2-dev
shouldn't work, no matter what rust-sdl2 uses for building itself. The
package will just contain a rlib file and put it inside
/usr/lib/rustlib/<target-triple>/.
There is a LOT of cross-over between package managers and build
systems. In fact, I'd argue that the distinction is very blurry, if not
misguided. Debian, for instance, provides:

apt-get -b source packagename

Which downloads and builds a package from source.

Many package managers, like the BSD ports, MAINLY download and build
from source. They're nothing but standardised wrappers for the many
build systems out there, along with (in some package managers, like
Debian's) standards for where the installed files should end up.

Other packages managers will ONLY build from source.



I think what you're mainly getting at, though, is why you need to care
about debian choosing to say:

apt-get install librust-sdl2-dev

When the Rust community says:

rustpkg -i rust-sdl


The problem is that, the whole concept of a package manager is to
standardise and maintain compatiblity between installed packages. So
when debian says:

apt-get install librust-sdl2-dev

AND you say:

rustpkg -i rust-sdl--berts-version

That's a conflict. Because two open source communities failed to work
together. BUT, debian, and others like BSD ports etc., very much do
their part, in providing ways to install librust-sdl2-dev etc. The part
that's missing is the metadata for rust-sdl--berts-version, which says,
"This package provides librust-sdl, so if you install this, don't
install some other librust-sdl as well."

Basically, I'm saying that, if we make a little effort to create open,
accessible package data, then everyone will find it easier to work with
us. That shouldn't be a foreign concept.
--
Lee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/71e3bad5/attachment.html>
Gaetan
2014-01-14 22:51:57 UTC
Permalink
you cannot stick build environment with one system. apt is now on every
system, you cannot use it under windows or mac.
and apt source simply checkout the source zip from repository, this is not
a proper build system.
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.

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..."

But, i tend to NOT recommend cmake if the final goal is to be integrated
into systems like debian.

-----
Gaetan



2014/1/14 Lee Braiden <leebraid at gmail.com>
Post by Jan Niklas Hasse
I don't understand what debian's package manager has to do with a build
system?
There's no reason why
apt-get install librust-sdl2-dev
shouldn't work, no matter what rust-sdl2 uses for building itself. The
package will just contain a rlib file and put it inside
/usr/lib/rustlib/<target-triple>/.
There is a LOT of cross-over between package managers and build systems.
In fact, I'd argue that the distinction is very blurry, if not misguided.
apt-get -b source packagename
Which downloads and builds a package from source.
Many package managers, like the BSD ports, MAINLY download and build from
source. They're nothing but standardised wrappers for the many build
systems out there, along with (in some package managers, like Debian's)
standards for where the installed files should end up.
Other packages managers will ONLY build from source.
I think what you're mainly getting at, though, is why you need to care
apt-get install librust-sdl2-dev
rustpkg -i rust-sdl
The problem is that, the whole concept of a package manager is to
standardise and maintain compatiblity between installed packages. So when
apt-get install librust-sdl2-dev
rustpkg -i rust-sdl--berts-version
That's a conflict. Because two open source communities failed to work
together. BUT, debian, and others like BSD ports etc., very much do their
part, in providing ways to install librust-sdl2-dev etc. The part that's
missing is the metadata for rust-sdl--berts-version, which says, "This
package provides librust-sdl, so if you install this, don't install some
other librust-sdl as well."
Basically, I'm saying that, if we make a little effort to create open,
accessible package data, then everyone will find it easier to work with
us. That shouldn't be a foreign concept.
--
Lee
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/5c9a8a14/attachment.html>
Lee Braiden
2014-01-14 23:07:02 UTC
Permalink
Post by Gaetan
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.
Post by Gaetan
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.
Post by Gaetan
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 :)
Post by Gaetan
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 :)
Post by Gaetan
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
Gaetan
2014-01-14 23:09:48 UTC
Permalink
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 <leebraid at gmail.com>
Post by Lee Braiden
Post by Gaetan
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
Post by Gaetan
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
Post by Gaetan
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
Post by Gaetan
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
Post by Gaetan
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140115/f5009814/attachment.html>
Martin DeMello
2014-01-14 23:15:47 UTC
Permalink
This would probably be a useful thing to have even if the rust project
doesn't officially end up adopting it as the One True Solution.

martin
Post by Gaetan
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 <leebraid at gmail.com>
Post by Lee Braiden
Post by Gaetan
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
Post by Gaetan
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
Post by Gaetan
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
Post by Gaetan
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
Post by Gaetan
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/68b62835/attachment-0001.html>
Jan Niklas Hasse
2014-01-14 23:15:13 UTC
Permalink
Post by Lee Braiden
Post by Gaetan
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.
Doesn't matter what the build system is, it's just another command to
execute specified for the debian package.
Post by Lee Braiden
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.
I wouldn't say *every* distro, etc. Here's an extreme example: Let's say
there's a distro which forces every source package to have its filenames
start with capital letters. Should we rename our files? I would say
definitely no. The distro has to adapt in that case.

The same goes for the build system: Debian can't handle executing
"rustpkg build" instead of "make"? It's their problem! (This is of
course false: Debian CAN handle exactly that)
Lee Braiden
2014-01-14 23:40:02 UTC
Permalink
Post by Jan Niklas Hasse
Post by Lee Braiden
Post by Gaetan
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.
Doesn't matter what the build system is, it's just another command to
execute specified for the debian package.
Well, the problem for package managers is threefold:

1) Builds involve dependencies: which source *packages* need to be
installed for that package to build, and of course, what dependencies
are requiring the CURRENT package to be installed in the first place.
It's not enough to just be able to BUILD a package; a package manager
has to know how, and why it's building something, where it will go when
installed, and what that will MEAN in terms of dependency resolution,
when the package is finally built and installed. Otherwise, it's not a
package MANAGER: it's just front end for downloaders/installers.

2) Some packages, if Rust becomes mainstream at all, will be available
from multiple sources, in multiple versions. For example, rust-std
might be included with a distro, as a standard package. So might
rust-sdl2. But maybe someone with that package installed decides to
install rust-newgame, which requires
rust-sdl2--bobs-greenthreads-patch. Then you have a conflict. If your
build script blindly installs rust-sdl2--bobs-greenthreads-patch over
rust-sdl2, it could break all rust packages that use SDL.

3) Packages take a lot of time to create and maintain. If we want
useful rust packages to reach as many people as possible, they should be
readily available in as many package managers as possible, in a
standard, non-conflicting package.

Now, there are two ways (that I can see so far) to achieve (3):

i) Expect all operating systems' and all distros' package
maintainers to find the resources to package lots of rust libraries and
programs.

ii) Make it easy for those maintainers to IMPORT rust libraries and
programs, using information that only we know, and that we will get
multiple emails requesting anyway, if we don't provide it up front, from
the start.
Post by Jan Niklas Hasse
Post by Lee Braiden
I wouldn't say *every* distro, etc. Here's an extreme example: Let's say
there's a distro which forces every source package to have its filenames
start with capital letters. Should we rename our files? I would say
definitely no. The distro has to adapt in that case.
That's a good point, and a good example of why we should think through
maximum compatibility carefully. I hadn't thought of that one, but now
that someone's thought of it, it should be easily solved by disallowing
case-dependency in package names. That way, different tools could
auto-capitalize, auto-title-case or whatever they prefer, as long as
they remember to lower-case when building the URL.

But yes, I take your wider point that there'll invariably be something
you don't think of first time around. It's that kind of thing I'm
talking about a version number for -- ensuring an upgrade path, just in
case.
Post by Jan Niklas Hasse
The same goes for the build system: Debian can't handle executing
"rustpkg build" instead of "make"? It's their problem! (This is of
course false: Debian CAN handle exactly that)
Right; building itself (for most things) isn't that hard, even if you're
running rustc instead of rustpkg, I suppose. It's dependencies and
package conflicts that are the real issue, not just building.
Otherwise, package management, DLL hell, RPM hell, etc., would have been
mostly solved as soon as most builds used make.
--
Lee
Jan Niklas Hasse
2014-01-14 23:49:10 UTC
Permalink
Post by Lee Braiden
2) Some packages, if Rust becomes mainstream at all, will be available
from multiple sources, in multiple versions. For example, rust-std
might be included with a distro, as a standard package. So might
rust-sdl2. But maybe someone with that package installed decides to
install rust-newgame, which requires
rust-sdl2--bobs-greenthreads-patch. Then you have a conflict. If your
build script blindly installs rust-sdl2--bobs-greenthreads-patch over
rust-sdl2, it could break all rust packages that use SDL.
This already works with rustpkg: When you type rustpkg install sdl2 it
installs it into the current working directory (locally) and there won't
be any conflicts with globally installed packages by the package
manager.
Post by Lee Braiden
3) Packages take a lot of time to create and maintain. If we want
useful rust packages to reach as many people as possible, they should be
readily available in as many package managers as possible, in a
standard, non-conflicting package.
I disagree! rustpkg should handle dependencies for building a rust
package. It can automatically know which packages are needed from
"extern mod" etc. apt-get and others are just unsuited for this.
Lee Braiden
2014-01-14 23:53:43 UTC
Permalink
Post by Jan Niklas Hasse
I disagree! rustpkg should handle dependencies for building a rust
package. It can automatically know which packages are needed from
"extern mod" etc. apt-get and others are just unsuited for this.
But that is exactly my point. Only Rust developers / tools / community
know that information, so we should make it available to others.

If you're trying to say, though, that we should hide that information so
we can control builds, I think that simply WON'T work WELL. Sure, it
can work, but there will be package conflicts; you will be making
people's lives harder.
--
Lee
Maciej Piechotka
2014-01-16 22:00:53 UTC
Permalink
Post by Lee Braiden
Post by Jan Niklas Hasse
I disagree! rustpkg should handle dependencies for building a rust
package. It can automatically know which packages are needed from
"extern mod" etc. apt-get and others are just unsuited for this.
But that is exactly my point. Only Rust developers / tools / community
know that information, so we should make it available to others.
If you're trying to say, though, that we should hide that information so
we can control builds, I think that simply WON'T work WELL. Sure, it
can work, but there will be package conflicts; you will be making
people's lives harder.
Possibly an useful note - in Gentoo there is tool to automatically
create ebuilds (read for simplicity - packages[1]) for Haskell
programs/libraries using cabal. The only thing you need is replace the
library names with packages name if the library is a binding to one.
Because there is a central repository (hackage) creation of package for
an application/library is as easy as:

% hackport app-editor/yi # Creates a 'package'
% emerge app-editor/yi # Installs a package

Or bindings:

% hackport dev-haskell/llvm-base # Creates a 'package'
% vim dev-haskell/llvm-base/llvm-base-<version>.ebuild
% emerge app-editor/yi # Installs a package

This picks ups all the changes, allows to select options (listed by
reading cabal files) etc. On the other hand cmake/autotools packages
require a bit more work.
(Some packages require further patching as authors assumed for example
that it'll be installed in /usr/local, or don't respect DESTDIR etc.)

For that reason I guess there would be benefit in having a single tool
which would make things uniform (say - rustpkg) as anyone maintaining a
rust repor for <insert your distribution here> would have just one tool
to work with instead of reading README file.

PS. Sorry if it double posted but gmane refused to send mail via NNTP
asking me to subscribe to this list even though I'm subscribe...

[1] This is a BIG lie for children but I don't want to explain it at
this moment

Lee Braiden
2014-01-14 22:33:39 UTC
Permalink
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
Post by George Makrydakis
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
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.
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
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<snip> However, I'd say there is a
stunning lack of existing build systems that actually
combine a clean design, flexibility, portability, and
performance<snip>
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": "author1 at 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": "0.1",
"max-version": "0.1",
"http://somehub.com/someuser/someotherproject/",
"min-git-tag": "04a453543",
"max-git-tag": "045ead634",
"http://someotherproject.com/somepath-${version}.tgz",
"distro-version-ok": "true"
}
},
"external-libs": {
"libssl": {
"min-version": "0.1",
"max-version": "0.1",
"http://somehub.com/someuser/someotherproject/",
"min-git-tag": "04a453543",
"max-git-tag": "045ead634",
"http://someotherproject.com/somepath-${version}.tgz"
"distro-version-ok": "true",
}
},
}
}
]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/2c380cf1/attachment.html>
Gaetan
2014-01-14 22:35:34 UTC
Permalink
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 <leebraid at gmail.com>
Post by Lee Braiden
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
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
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.
Post by Lee Braiden
Post by Patrick Walton
Post by comex
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
Post by George Makrydakis
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<snip>
However, I'd say there is a stunning lack of existing build systems
that actually combine a clean design, flexibility, portability, and
performance<snip>
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": "author1 at someplace.com" <author1 at 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",
"http://somehub.com/someuser/someotherproject/",
"min-git-tag": "04a453543",
"max-git-tag": "045ead634",
"http://someotherproject.com/somepath-${version}.tgz",
"distro-version-ok": "true"
}
},
"external-libs": {
"libssl": {
"min-version": "0.1",
"max-version": "0.1",
"http://somehub.com/someuser/someotherproject/",
"min-git-tag": "04a453543",
"max-git-tag": "045ead634",
"http://someotherproject.com/somepath-${version}.tgz"
"distro-version-ok": "true",
}
},
}
}
]
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/31462a97/attachment-0001.html>
Lee Braiden
2014-01-14 22:58:53 UTC
Permalink
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
Post by Gaetan
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 <leebraid at gmail.com <mailto:leebraid at 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
Post by George Makrydakis
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
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.
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
<irrequietus at gmail.com>
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<snip> However,
I'd say there is a stunning lack of existing build
systems that actually combine a clean design,
flexibility, portability, and performance<snip>
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":"author1 at someplace.com" <mailto:author1 at 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": "0.1",
"max-version": "0.1",
"http://somehub.com/someuser/someotherproject/",
"min-git-tag": "04a453543",
"max-git-tag": "045ead634",
"http://someotherproject.com/somepath-${version}.tgz",
"distro-version-ok": "true"
}
},
"external-libs": {
"libssl": {
"min-version": "0.1",
"max-version": "0.1",
"http://somehub.com/someuser/someotherproject/",
"min-git-tag": "04a453543",
"max-git-tag": "045ead634",
"http://someotherproject.com/somepath-${version}.tgz"
"distro-version-ok": "true",
}
},
}
}
]
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org <mailto:Rust-dev at mozilla.org>
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/121962bb/attachment-0001.html>
Corey Richardson
2014-01-14 23:43:56 UTC
Permalink
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.
Lee Braiden
2014-01-14 23:54:06 UTC
Permalink
Post by Corey Richardson
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
Corey Richardson
2014-01-15 06:34:04 UTC
Permalink
Post by Lee Braiden
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
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.
Post by Lee Braiden
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)
Lee Braiden
2014-01-15 09:30:35 UTC
Permalink
Post by Corey Richardson
Post by Lee Braiden
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
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
George Makrydakis
2014-01-15 10:18:55 UTC
Permalink
+1, even more than that.
Post by Corey Richardson
Post by Lee Braiden
Post by Corey Richardson
This thread is deviating from its purpose. The idea isn't to hash
out a
Post by Lee Braiden
Post by Corey Richardson
generic build system for all of Rust, merely for the compiler +
stdlib.
Post by Lee Braiden
I think it naturally progressed, because some people wanted to
discuss a
Post by Lee Braiden
more generic solution.
But fair enough... if the only goal is to build rust, I've very
little
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140115/623a99e7/attachment-0001.html>
George Makrydakis
2014-01-15 11:05:28 UTC
Permalink
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?
Post by Corey Richardson
Post by Corey Richardson
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140115/f56c41a6/attachment.html>
Gaetan
2014-01-15 13:46:58 UTC
Permalink
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
ninja<http://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 <irrequietus at gmail.com>
Post by George Makrydakis
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?
Post by Lee Braiden
Post by Corey Richardson
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
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140115/944e1fa9/attachment.html>
George Makrydakis
2014-01-15 13:56:14 UTC
Permalink
For what concerns the entire discussion so far, I think that ninja would be an excellent suggestion as a starting point in cleaning up the build process for both Rust compiler and the standard library.

Because of such a refactoring, what could follow afterwards (post - 1.0 likely) could undoubtedly have better chances in being even cleaner and more useful for both compiler and standard library building.

Under current circumstances, it is an alternative with merit.
Post by Gaetan
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
ninja<http://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 <irrequietus at gmail.com>
Post by George Makrydakis
As an interim solution, any proven build system will do regardless of
preference. Given the current status quo of Rust's evolving
condition, the
Post by George Makrydakis
choice should weigh on the side compatible with what the core
developers
Post by George Makrydakis
use since they build way too often.
Simplify the build process by reducing number of tools required,
going
Post by George Makrydakis
towards a single tool if possible. That would make the option of
"rusting"
Post by George Makrydakis
an alternative, future solution far easier to adopt if that would
still be
Post by George Makrydakis
an option.
Should a poll be made instead of these threads?
Post by Lee Braiden
Post by Corey Richardson
This thread is deviating from its purpose. The idea isn't to hash
out
Post by George Makrydakis
Post by Lee Braiden
Post by Corey Richardson
a generic build system for all of Rust, merely for the compiler +
stdlib.
Post by George Makrydakis
Post by Lee Braiden
I think it naturally progressed, because some people wanted to
discuss a
Post by George Makrydakis
Post by Lee Braiden
more generic solution.
But fair enough... if the only goal is to build rust, I've very
little
Post by George Makrydakis
Post by Lee Braiden
Please choose something cross-platform that's as standard as
possible,
Post by George Makrydakis
Post by Lee Braiden
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140115/949657ad/attachment-0001.html>
Jack Moffitt
2014-01-15 14:06:58 UTC
Permalink
Post by Gaetan
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.
Post by Gaetan
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.
Gaetan
2014-01-15 15:34:29 UTC
Permalink
I just hate the "if/elseif/else" block in CMake list, that's all :)

One of the major advantage of cmake is the huge list of supported
dependency scripts that is provided out of the box. You want to use QT4 in
your software, just write 'FindPackage(QT4)'. That is a good inspiration.

-----
Gaetan



2014/1/15 Jack Moffitt <jack at metajack.im>
Post by Jack Moffitt
Post by Gaetan
used. The makefile macro may be rewritten in CMakeList.txt stuff, but
this
Post by Gaetan
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.
Post by Gaetan
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140115/ebaef846/attachment.html>
Ben Boeckel
2014-01-16 05:42:23 UTC
Permalink
Post by Gaetan
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
George Makrydakis
2014-01-15 09:38:19 UTC
Permalink
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?
Post by Lee Braiden
Post by Lee Braiden
Another point is that we don't really need a massively complicated
"build
Post by Lee Braiden
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
Post by Lee Braiden
(excluding comments). Another few lines to figure out whether to
build a
Post by Lee Braiden
library or an executable, another few to run rustc with the list of
files,
Post by Lee Braiden
OR to output that list to a Makefile, or a CMakeList.txt, or an IDE
project
Post by Lee Braiden
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140115/7f4f5707/attachment.html>
Robert Knight
2014-01-15 10:06:46 UTC
Permalink
Post by Lee Braiden
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.
Post by Lee Braiden
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?
Post by Corey Richardson
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Gaetan
2014-01-15 10:08:27 UTC
Permalink
I agree. If you take this path, use Cmake or scons.

-----
Gaetan



2014/1/15 Robert Knight <robertknight at gmail.com>
Post by Lee Braiden
Post by Lee Braiden
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.
Post by Lee Braiden
This is why I am reserving commentation right now and have been
consistently
Post by Lee Braiden
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?
Post by Lee Braiden
On Tue, Jan 14, 2014 at 5:33 PM, Lee Braiden <leebraid at 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
Post by Lee Braiden
(excluding comments). Another few lines to figure out whether to
build
Post by Lee Braiden
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140115/12c0acf8/attachment.html>
George Makrydakis
2014-01-15 10:17:06 UTC
Permalink
As Corey Richardson already said, the threads in these posts are deviating from their intended purpose.

Can we talk again about what the system used for building the Rust compiler and standard library should eventually be ?

It is as if we are discussing several, unrelated issues at once.
Post by Lee Braiden
Post by Lee Braiden
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.
Post by Lee Braiden
This is why I am reserving commentation right now and have been
consistently
Post by Lee Braiden
asking about Rust providing a build system in all other emails. Can
the
Post by Lee Braiden
other commenters refocus with the rest of us back to the original
question?
Post by Lee Braiden
On Tue, Jan 14, 2014 at 5:33 PM, Lee Braiden <leebraid at 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
Post by Lee Braiden
(excluding comments). Another few lines to figure out whether to
build
Post by Lee Braiden
a
library or an executable, another few to run rustc with the list
of
Post by Lee Braiden
files,
OR to output that list to a Makefile, or a CMakeList.txt, or an
IDE
Post by Lee Braiden
project
file.
This thread is deviating from its purpose. The idea isn't to hash
out
Post by Lee Braiden
a generic build system for all of Rust, merely for the compiler +
stdlib.
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140115/edefe42e/attachment.html>
Gaetan
2014-01-14 22:32:17 UTC
Permalink
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 <leebraid at gmail.com>
Post by comex
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
Post by George Makrydakis
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<snip>
However, I'd say there is a stunning lack of existing build systems
that actually combine a clean design, flexibility, portability, and
performance<snip>
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": "author1 at 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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/48d3687e/attachment-0001.html>
Jan Niklas Hasse
2014-01-10 08:54:21 UTC
Permalink
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 <corey at octayn.net>
Post by Corey Richardson
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?)
1. Work on all the platforms we support
2. Be able to track dependencies.
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)
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
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/ce7c572c/attachment.html>
Gaetan
2014-01-10 10:06:46 UTC
Permalink
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 <jhasse at gmail.com>
Post by Jan Niklas Hasse
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 <corey at octayn.net>
Post by Corey Richardson
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?)
1. Work on all the platforms we support
2. Be able to track dependencies.
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)
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
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/47e31bbd/attachment.html>
Robert Knight
2014-01-10 11:19:26 UTC
Permalink
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.
Post by Gaetan
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 <jhasse at gmail.com>
Post by Jan Niklas Hasse
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 <corey at octayn.net>
Post by Corey Richardson
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?)
1. Work on all the platforms we support
2. Be able to track dependencies.
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)
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
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
SiegeLord
2014-01-10 15:17:00 UTC
Permalink
Post by George Makrydakis
Hello,
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
Gaetan
2014-01-10 15:53:14 UTC
Permalink
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 <slabode at aim.com>
Post by SiegeLord
Post by George Makrydakis
Hello,
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/d1619845/attachment-0001.html>
Erick Tryzelaar
2014-01-10 18:38:38 UTC
Permalink
I'm personally in favor of us making our own build system, but I am
completely biased as I've already written one multistage cross-compiling
build system in Python:

https://github.com/felix-lang/fbuild

The reason why went crazy and built one was for a couple reasons. Before
Rust I worked on the Felix language, which had some complex needs for the
build system. First off, we wanted to support using MSVC without Cygwin.
Second, Building Felix used three languages as part of it's build. The
compiler was written in O'Caml, the runtime in C++, and the standard
library was in Felix. We also used a couple parser generators. Third, Felix
was a cross compiler, so we would configure and build 3 compilers. The
first generated a compiler for architecture A that could make a compiler
for architecture B who's output targeted architecture C.

As you can see, it was a complex problem. Before I started working on
FBuild, I evaluated a ton of other build systems, but they all had a bunch
of issues trying to support something like this. The biggest one was due to
the very nature of a declarative build system. There really are two phases
to these systems. First is a phase to gather up all the dependencies and
build a tree of work to do. Second is the evaluation of that tree. Things
get rather messy when you need to run a command and use it's output to
declare more dependencies. A simple example of this is using `gcc -M` to
get all the C file dependencies. This is typically supported by all build
systems. A more complex one is something like `doxygen`, which requires
manual inspection of the file system to determine dependencies.

When you combine the two phases with multiple stages it gets really
complicated. Code generators like Autoconf and CMake use macro
substitutions which can be very difficult to decipher. Systems like SCons
can be a little better because you can run arbitrary code at a given step
in the dependency tree, but there's some impedance mismatches with how you
define the build and run code. You can't do something like this:

print 'before'

Program('foo.c')

print 'after

And have the prints bracket the building of 'foo.c'. Futhermore, you need
to work with a shared environment to declare command options, and I found
that to be difficult to work with when doing a multistage build. Finally,
it still seems to be suffering from some poor performance issues:

http://blog.melski.net/2013/12/11/update-scons-is-still-really-slow/

Waf and Tup were still pretty new at the time I started FBuild, and if I
recall correctly, I think they still had trouble doing a simple multistage
build.

What I ended up doing with FBuild was to make a build system that was
centered around the idea of caching function calls. I made it in Python,
and it had a similar style to SCons, where you would write:

def build(ctx):
c = fbuild.builders.c.guess_static(ctx)

print 'before'

lib = c.build_lib('static', ['lib.c'])
exe = c.build_exe('exe', ['exe.c'], libs=[lib])

print 'after'

But each function call actually built the output (or loaded the results
from the cache), and the printouts actually happen when they look to happen.

Doing multiple stages in this way was really simple. You just use functions:

def my_c_compiler(ctx, c):
exe = c.build_exec('my-gcc', ['my_gcc.c'])
return fbuild.builders.c.gcc.static(ctx, exe)

def build(ctx):
c = fbuild.builders.c.guess_static(ctx)
new_c = my_c_compiler(ctx, c)
new_new_c = my_c_compiler(ctx, new_c)

It worked well, and was able to run on all our platforms and support some
nifty auto configuration support too for many c libraries. It could also
build in parallel, but there were some limitations to it because Python did
not play well with exceptions, threads, and signals.

I've been planning on reimplementing FBuild in rust for quite some time,
but I haven't had the time yet to do it beyond a couple experiments. We
already have some pieces of this approach in libextra though. Graydon took
my caching-of-functions idea and turned it into `extra::workcache`. It
wouldn't be *that* hard to port my ideas over from python though. When I
get home tonight I'll try to upload my work in progress somewhere.
Post by Gaetan
I also agree that the way waf works is quite weird to use, but this is
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 <slabode at aim.com>
Post by SiegeLord
Post by George Makrydakis
Hello,
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/fbc441de/attachment-0001.html>
Jan Niklas Hasse
2014-01-10 16:53:56 UTC
Permalink
2014/1/10 Robert Knight <robertknight at gmail.com>
Post by George Makrydakis
Hello,
- 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).
Post by George Makrydakis
- 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
Thad Guidry
2014-01-10 17:38:56 UTC
Permalink
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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/602ab659/attachment.html>
Robert Knight
2014-01-10 17:57:32 UTC
Permalink
Post by Jan Niklas Hasse
- 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.
Post by Jan Niklas Hasse
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Patrick Walton
2014-01-10 18:56:03 UTC
Permalink
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
Post by Thad Guidry
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/f02e07fb/attachment.html>
james
2014-01-11 12:03:54 UTC
Permalink
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.
George Makrydakis
2014-01-11 16:53:54 UTC
Permalink
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.
Post by james
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140111/49b632b2/attachment.html>
Brian Anderson
2014-01-10 19:13:32 UTC
Permalink
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).
Post by Corey Richardson
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?)
1. Work on all the platforms we support
2. Be able to track dependencies.
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)
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
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 at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
György Andrasek
2014-01-10 21:26:09 UTC
Permalink
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.
Jan Niklas Hasse
2014-01-13 14:46:43 UTC
Permalink
Post by Corey Richardson
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.
Loading...