[rust-dev] RFC: Future of the Build System

Lee Braiden leebraid at gmail.com
Tue Jan 14 14:11:19 PST 2014


On 14/01/14 20:51, George Makrydakis wrote:
>
> That would be a good start. But are you advocating that it should be 
> third party tools thatcshould be given guidelines on how to comply? 
> What would be their incentive to do so? Or should this be used as a 
> basis for creating a prototype deploying duch information... which 
> would inevitably ask again:
>
> Should Rust have its own build tool, given your proposal of 
> standardized representational information ? Dealing with such metadata 
> forces you to design a new system.
>

I guess I'm saying that, no matter what solution you choose:

a) People will want their own version, either because they know and 
prefer something else, OR just because they run, say, debian, and it 
manages 26000 packages on their system, and they want Rust to be managed 
that way too.**

b) This kind of information will be needed

** For instance, Debian has tools to create debian packages from git 
repositories, PHP's pear packages, perl packages, google earth tarballs, 
etc.

Arch, BSD ports, and the like import packages using a thin wrapper 
around whatever package system upstream developers use.  There's a will, 
in Linux, in Mac, with MacPorts, in cygwin, etc., and in mobile, to 
integrate package management into one system for all.  We don't 
necessarily have to provide "build" tools for each platform, so 
integration tools for each IDE, syntax highlighting for each editor, or 
API documentation/tags for each IDE.  At least, to start with, all we 
need to do is make it possible for people who want to do these things, 
to do them.

But, what I think is pretty important, is to establish the standard as 
early as possible, to allow people to build tools for as many Rust 
packages as possible.  In many ways, speaking as a general developer 
rather than a rust developer, knowing that any rust package / repository 
will contain a .rust-info file, say, which tells me all the metadata I 
need to know to integrate that package into my website, buildtool, or 
whatever... that's much more valuable to me, than knowing that I can 
download some package, on any of 3 platforms, and it'll just just 
build.  The tool is short term convenience, but the data lets me build 
short term tools AND long-term infrastructure.


-- 
Lee


>
>
> Lee Braiden <leebraid at gmail.com> wrote:
>
>     On 14/01/14 17:25, Patrick Walton wrote:
>
>         On 1/14/14 1:29 AM, comex wrote:
>
>             On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
>             <irrequietus at gmail.com> wrote:
>
>                 Again, note that this rather long thread is about
>                 discussing in the end what the official stance should
>                 be. There is no valid reason other than lack of
>                 manpower and / or language immaturity for having to
>                 depend on ruby, python, autotools, cmake or whatever
>                 else in order to build rust software. 
>
>             There is no reason every language should have its own
>             build system written from scratch (or package manager, for
>             that matter); the goals of each language community are
>             really mostly identical<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",
>
>                                   "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",
>                           }
>                   },
>              }
>          }
>     ]
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/8236f568/attachment.html>


More information about the Rust-dev mailing list