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

Lee Braiden leebraid at gmail.com
Tue Jan 14 14:58:53 PST 2014


Gaetan,

I agree, it's important to think of use cases up-front, and I've tried 
to do that below, too.  If you can add any necessary features or ideas, 
please do.  And if Rustics reach consensus that this is the preferred 
approach, then we should definitely formalise the decision process about 
selecting use cases, making sure they're all covered, etc.

However, from experience, it's IMPOSSIBLE to think of EVERY use case up 
front.  Simply not knowing what technology will be invented in five 
years prevents it.  No matter how hard you try to envisage all 
circumstances, and all future use-cases, something will just be 
obviously missing, in hindsight.  The best standards ALWAYS tag 
versions, and leave room for forwards-compatible upgrades.  It's the 
very reason we have to deal with packages for lots of different library 
versions: eventually, you want to deprecate old stuff, and embrace new 
stuff, and you need some version number to tell which is which.  This 
shouldn't be threatening; it's the EASY, SAFE, GENTLE way to add new 
features. It's what every sensible protocol and standard on the internet 
does, for instance, right down to IP itself.


-- 
Lee


On 14/01/14 22:35, Gaetan wrote:
> i disagree, the data structure needs to be developed with the majority 
> of use case possible. you cannot rely on just "extending it" later 
> when new feature will be needed, that will NOT work.
>
> -----
> Gaetan
>
>
>
> 2014/1/14 Lee Braiden <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
>
>
>
>     On 14/01/14 20:51, George Makrydakis wrote:
>>
>>     That would be a good start. But are you advocating that it should
>>     be third party tools thatcshould be given guidelines on how to
>>     comply? What would be their incentive to do so? Or should this be
>>     used as a basis for creating a prototype deploying duch
>>     information... which would inevitably ask again:
>>
>>     Should Rust have its own build tool, given your proposal of
>>     standardized representational information ? Dealing with such
>>     metadata forces you to design a new system.
>>
>>
>>
>>     Lee Braiden <leebraid at gmail.com> <mailto: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>
>>                 <mailto: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"  <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",
>>
>>                                       "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",
>>                               }
>>                       },
>>                  }
>>              }
>>         ]
>>
>
>
>     _______________________________________________
>     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>


More information about the Rust-dev mailing list