Ce serveur Gitlab sera éteint le 30 juin 2020, pensez à migrer vos projets vers les serveurs gitlab-research.centralesupelec.fr et gitlab-student.centralesupelec.fr !

  1. 07 Oct, 2011 3 commits
    • Ryan C. Thompson's avatar
      Remove extraneous parentheses · 58e7b8ee
      Ryan C. Thompson authored
      58e7b8ee
    • Ryan C. Thompson's avatar
      0945dd27
    • Ryan C. Thompson's avatar
      Don't assume that first build command is a string · 508fb7e1
      Ryan C. Thompson authored
      Build commands are supposed to be either strings or lists of strings.
      But the code for deciding whether to eval the :build property only
      checks for a string, not a list. This commit fixes this, so that a
      build property whose commands are all lists of strings should no
      longer cause an error. Evaluation of the :build property now only
      happens when the car is a symbol, since that is the only time that
      evaluation would not result in an error.
      
      Also in this commit:
      
      * Ensure build commands are all strings or lists of strings and raise
        an error otherwise. The check happens after flattening, so nested
        lists of strings should also pass.
      * A few syntax fixes
      * Add a function "el-get-list-of-strings-p"
      508fb7e1
  2. 06 Oct, 2011 2 commits
    • Ryan C. Thompson's avatar
      Warn for build commands that rely on whitespace-splitting · 9be99cc3
      Ryan C. Thompson authored
      El-get-build allows a command to be specified as a single string. It
      will split that string on whitespace into a list of strings, and each
      element of that list will eventually be shell-quoted (by
      `el-get-start-process-list`). This is wrong behavior that can easily
      cause an innocent command to be over-escaped or split into too many
      arguments, or both. For example, consider a build process that
      involves running the following command:
      
          make SOME_OPTION="this is the option value"
      
      Written as a string in Elisp, that would be:
      
          "make SOME_OPTION=\"this is the option value\""
      
      After splitting on whitespace and then shell-quoting and then passing
      the result to the shell, the above command is equivalent to running
      the following at the shell:
      
          "make" "SOME_OPTION=\"this" "is" "the" "option" "value\""
      
      See the problem? What was once a single argument is now five, and the
      quotation marks have been inappropriately quoted. For this reason, I
      think auto-whitespace splitting should probably be deprecated. The
      command should either be a single string, which would be interpreted
      as a command to be run with no arguments, or a list of strings, like
      this:
      
          '("make" "SOME_OPTION=\"this is the option value\"")
      9be99cc3
    • Ryan C. Thompson's avatar
      Use a list of arguments instead of a single string for command · 3fa180a6
      Ryan C. Thompson authored
      The `el-get-install-or-init-info` composed a command as a single
      pre-quoted string using `concat` and `shell-quote-argument`. It is
      better to make the command a list of unquoted arguments, which is what
      this commit does.
      3fa180a6
  3. 05 Oct, 2011 1 commit
  4. 03 Oct, 2011 1 commit
  5. 30 Sep, 2011 1 commit
  6. 22 Sep, 2011 1 commit
    • Dimitri Fontaine's avatar
      Fix the refactoring so that it actually works. · 8db0c4d4
      Dimitri Fontaine authored
      This includes teaching methods that they now work with a symbolp PACKAGE,
      some more cleaning up, and some load-path adjustments now that a part of the
      code is in a subdirectory (methods).
      
      Also include some of the tests used to convince oneself that the refactoring
      didn't break any and all use cases for el-get, with some rough documentation
      about how to use them.
      8db0c4d4
  7. 20 Sep, 2011 1 commit