Gaetan,

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

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


--
Lee


On 14/01/14 22:35, Gaetan wrote:
i disagree, the data structure needs to be developed with the majority of use case possible. you cannot rely on just "extending it" later when new feature will be needed, that will NOT work.

-----
Gaetan



2014/1/14 Lee Braiden <leebr...@gmail.com <mailto:leebr...@gmail.com>>

    Another point is that we don't really need a massively complicated
    "build system" right now, as far as I know.

    I don't know rust well yet, but it's a two-line script to load
    this data (excluding comments).  Another few lines to figure out
    whether to build a library or an executable, another few to run
    rustc with the list of files, OR to output that list to a
    Makefile, or a CMakeList.txt, or an IDE project file.

    With the data, you could build any tool of your choice, to use
    (almost) any tool of your choice, with a few lines in the language
    of your choice.

    And, you can evolve it all later, into something better.  And the
    data format could be extended too.  I should add that the data
    format should have a version number, so tools could parse new
    versions differently, or even read this file, see that it's
    version 2, and that a better, more file format with a different
    filename should be used instead.


-- Lee



    On 14/01/14 20:51, George Makrydakis wrote:

    That would be a good start. But are you advocating that it should
    be third party tools thatcshould be given guidelines on how to
    comply? What would be their incentive to do so? Or should this be
    used as a basis for creating a prototype deploying duch
    information... which would inevitably ask again:

    Should Rust have its own build tool, given your proposal of
    standardized representational information ? Dealing with such
    metadata forces you to design a new system.



    Lee Braiden <leebr...@gmail.com> <mailto:leebr...@gmail.com> wrote:

        On 14/01/14 17:25, Patrick Walton wrote:

            On 1/14/14 1:29 AM, comex wrote:

                On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
                <irrequie...@gmail.com>
                <mailto:irrequie...@gmail.com> wrote:

                    Again, note that this rather long thread is about
                    discussing in the end what the official stance
                    should be. There is no valid reason other than
                    lack of manpower and / or language immaturity for
                    having to depend on ruby, python, autotools,
                    cmake or whatever else in order to build rust
software.
                There is no reason every language should have its own
                build system written from scratch (or package
                manager, for that matter); the goals of each language
                community are really mostly 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":"auth...@someplace.com"  
<mailto:auth...@someplace.com>,
"web": "http://someplace.com";,
                      },
                  },

                  "copyright": {
                      "license-file":        "docs/LICENSE.TXT",
                      "license-flags":    "SHAREALIKE | ATTRIBUTION |
        ADVERTISING_CLAUSE",
                  },

                  "build-info": {
                      "build-type":        "library",
                      "target":             "libx.so  <http://libx.so>"
                      "source-files":     [ "src/*.rs", "somedir/a_file.rs  
<http://file.rs>" ],
                  },

                  "developer-support-info": {
                       "rust-ide-doc-file": "docs/libx.rustapi",
                       "rust-ide-completion-file": "docs/libx.rusttags",
                  },

                  "dependencies": {
                      "rust-projects":  {
                              "someotherproject": {        # from that projects
        "project" -> "name"
        entry

                                      # following fields are optional; any
        specified filter the list
                                      # the list of suitable candidates.

                                      "min-version": "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@mozilla.org <mailto:Rust-dev@mozilla.org>
    https://mail.mozilla.org/listinfo/rust-dev



_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to