discussion

[timotheecour]

• after properly fix #10030 by skipping all external configs nim-lang/Nim#10324 is merged, simply the travis file, eg:

If the git repo contains a config.nims, temporarily move it, else it fails the
      # building of koch.

• you need set -e .travis.yml as done here https://github.com/nim-lang/Nim/blob/fbd6743ea1db89eef3dd89ceb7c0cdcb648c8055/.travis.yml#L35 so it fails 1st error ; it'll make the script more robust, and probably simpler

• instead of a giant (and complex) https://github.com/kaushalmodi/hello_musl/blob/master/config.nims why not instead have a bootstrapping nim binary where u can enjoy full benefits of nim (instead of nims limitations), analog to koch.nim eg:

travis:
calls `sh build_all.sh` to build nim
then calls: `nim c -r musl.nim example.nim` where `musl.nim` contains the samle logic as in `config.nims` but as a nim file

nim musl foo.nim would become: nim c -r musl.nim foo.nim (with proper caching, u'd only pay (minimal IMO) cost of building musl.nim the 1st time; alternatively u can turn your repo into a proper nimble project that contains a binary musl that gets built; u can even keep the musl task but it'd forward to : exec "musl ..."

• likewise, instead of a giant travis.yml (which would be a pain to port to appveyor), why not move bulk of it to a bootstraping nim file (maybe same as above) that takes care of everythign once there is an initial nim built; ie, same spirit as what i did here: [CI] fix #10041 move bulk of travis and appveyor logic to koch.nim nim-lang/Nim#10183 which greatly simplified my life after that PR

• is this actually needed (ie makes a practical difference)? if so, could we benefit from it in Nim's travis/appveyor too?

     # After building nim, wipe csources to save on cache space.
      rm -rf csources

• ditto with:
  git clone --single-branch --branch devel --depth=1 "${NIMREPO}" "${NIMDIR}" instead of what we have in Nim's travis (simply git clone)

• replace a bunch of lines with: sh build_all.sh eg:

rm -rf nim
      mkdir -p nim
      git clone --single-branch --branch devel --depth=1 "${NIMREPO}" "${NIMDIR}"
      cd "${NIMDIR}" || exit
      [ -d csources ] || git clone --depth 1 https://github.com/nim-lang/csources.git
      cd csources
      sh build.sh
      cd ..
      ./bin/nim c koch
      ./koch boot -d:release
      # After building nim, wipe csources to save on cache space.
      rm -rf csources

if that doesn't work for u, maybe we should make it work for u by improving sh build_all.sh (eg making optional some of the stuff u may not need like koch tools)
=> that way, things r more DRY

• regarding ur TODO:
  Figure out how to have nimble install install the binary generated by nim musl
  happy to help if u tell me where you're blocking

[kaushalmodi]

Hello @timotheecour, thanks for this detailed feedback!

you need set -e .travis.yml as done here

Done. Thanks! I am a big fan of the unofficial bash script mode, but I forgot to use that in Travis.

instead of a giant (and complex) config.nims why not instead have a bootstrapping nim binary where u can enjoy full benefits of nim (instead of nims limitations), analog to koch.nim

I intend to use a common config.nims for all my projects like this. With config.nims, I simply curl it to a new project and nim musl .. just works. With musl.nim, you need to build it first and so that is less preferred. Also the code will look about the same even if it's ported to musl.nim right?

likewise, instead of a giant travis.yml (which would be a pain to port to appveyor), why not move bulk of it to a bootstraping nim file (maybe same as above) that takes care of everythign once there is an initial nim built; ie, same spirit as what i did here: nim-lang/Nim#10183 which greatly simplified my life after that PR

I was bothered by bash scripts inline in Travis earlier, but not such much after I discovered the multi-line YAML syntax. Also, I haven't used Appveyor, and don't intend to use it as Travis works for my projects. So I didn't yet think about having to port Travis stuff to Appveyor :)

is this actually needed (ie makes a practical difference)?

I haven't measured but I didn't like the idea of caching and then restoring ~250MB of csources. It very likely that building it from scratch as I am doing right now is taking much more time.

I need to reconsider if I really need to rebuild nim from csources each time. Thanks.

if so, could we benefit from it in Nim's travis/appveyor too?

I am not sure.

ditto with: git clone --single-branch --branch devel --depth=1 "${NIMREPO}" "${NIMDIR}"

You mean why I used --single-branch? the same reason .. to reduce cache size. I am building only from devel. So I don't need master and dozen other branches to be cloned.

replace a bunch of lines with: sh build_all.sh eg: .. if that doesn't work for u, maybe we should make it work for u by improving sh build_all.sh (eg making optional some of the stuff u may not need like koch tools)

Yes, you understood why I wasn't using build_all.sh. I don't need to build all the tool when in most of the cases, I only need to create the nim binary, or may be nimble too at the most. This is to reduce the build time. It would be nice to make the tools building optional.

regarding ur TODO: Figure out how to have nimble install install the binary generated by nim musl
happy to help if u tell me where you're blocking

This is the blocking issue: nim-lang/nimble#542. nimble install always runs nim c .. and then installs the generated binary. It would be nice to specify in nimble what command to run for install (and build) targets. But again this is a very minor issue. So I haven't pursed this actively.

---

So far, for each new Nim project, I need to copy just the .travis.yml, and it works almost as is with very little tweaks if needed (and thus I do weird things like this in the .travis.yml :)), which also does a curl of my common config.nims.

[kaushalmodi]

Thinking aloud, may be I should move part of my .travis.yml and the config.nims to a custom koch like nim project like you suggested. Thanks for the suggestion!