kaushalmodi / hello_musl Goto Github PK

thanks for the project, it's a great reference. it would be nice to have a target for a static curl build.

Ref: https://github.com/emk/rust-musl-builder/blob/14ff0ce4bf84857e83a026eac335c4299ee8518b/Dockerfile#L72-L79

Hi, thanks for this, it was incredibly helpful to me, I found out I was getting some errors regarding regular expressions, turns out
for them to work one must pass the --enable-unicode-properties flag to the pcre config command, this is more a pcre thing anyway, but I think talking about it would be cool, anyhow if someone has the same issue I had this issue could be a good place to look.

Thanks once again!

Ref: https://gitter.im/nim-lang/Nim?at=5bc0c190435c2a518e961a75

https://crosstool-ng.github.io/

leorize here:

actually, if you integrate crosstool-NG, you might be able to write a .nims that can spit out windows, mac,... binaries

• after 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: 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

Ref: https://gitter.im/nim-lang/Nim?at=5bbe4163ae7be9401633eb18

/cc @xmonader: I will update here about this if I learn something.