Arch Linux (tar-xz) package

[nia-e]

There seems to be no clear way to turn NGS source code into a tarball, and no PKGBUILD is provided.

[zglozman]

Just compile using cmake and then use make install. I am with you I suffer from the same problem we will resolve it soon and There will be an apt install Ngs one day

[ilyash]

It might take some time but it's in TODO. Also I'll try to make single binary with old libc as only dependency.

[0x647262]

I'll see what I can do about this

I'm thinking of packaging the following variants:

aur/ngs
aur/ngs-git
aur/ngs-musl
aur/ngs-musl-git

[ilyash]

@devopsdeluxe , great!

Let me know if you have any questions or prefer to talk directly.

[ilyash-b]

The package should include vim highlighting

[0x647262]

@ilyash @ilyash-b (which one should I tag in the future?)

Mind assigning this to me so it doesn't slip off my radar again?

[ilyash-b]

Any of them will work.

Apparently you need to be organization member to be assigned to a ticket. I've just sent invitation.

[0x647262]

I've accepted the invitation.

[0x647262]

I have the initial implementation of the ngs-git PKGBUILD working, but I'm still thinking about how to handle the bootstrapping process... I think the ideal method for that right now would be to include a script with the package that:

1. Exports the NGS_DIR and NGS_BOOTSTRAP environment variables.
2. Optionally appends them to the user's default $SHELL configuration file.

UPDATE:

https://aur.archlinux.org/packages/ngs-lang/

https://aur.archlinux.org/packages/ngs-lang-git/

[ilyash-b]

I have the initial implementation of the ngs-git PKGBUILD working

Cool!

how to handle the bootstrapping process

The idea was that one shouldn't generally set NGS_BOOTSTRAP nor NGS_DIR.

NGS has a hardcoded list of places to be looked for the bootstrap.ngs file:

	// First check $HOME/.bootstrap.ngs and then:

	static char *places[] = {
		"/usr/local/etc/ngs/bootstrap.ngs",
		"/usr/local/lib/ngs/bootstrap.ngs",
		"/etc/ngs/bootstrap.ngs",
		"/usr/lib/ngs/bootstrap.ngs",
		NULL
	};

One can use NGS_BOOTSTRAP to override the lookup.

In next phase, same directories are scanned for stdlib.ngs. The first directory that has stdlib.ngs is the "NGS directory", which again can be overridden by the NGS_DIR.

If needed, we can add more paths to look in so that Arch Linux installation wouldn't require setting NGS_BOOTSTRAP or NGS_DIR.

There are also plans for "Allow easy installation of different NGS versions on same machine" - #35 . You are welcome to comment on.

[ilyash-b]

I see you have both ctest and then you run test.ngs. I think this is redundant because ctest runs test.ngs.

check() {
  cd "${pkgname/-lang}-${pkgver}/build"

  ctest

  export NGS_DIR='../lib'
  export NGS_BOOTSTRAP="${NGS_DIR}/bootstrap.ngs"
  ./ngs ../test.ngs
}

[ilyash-b]

Heads up: #51 - In future NGS_BOOTSTRAP and NGS_DIR should be eliminated in favor of single search path.

[0x647262]

I see you have both ctest and then you run test.ngs. I think this is redundant because ctest runs test.ngs.

Fixed!

Heads up: #51 - In future NGS_BOOTSTRAP and NGS_DIR should be eliminated in favor of single search path.

I'll put some thought into it during the week and make a comment there once I have an opinion on it.

[ilyash-b]

I'll put some thought into it during the week and make a comment there once I have an opinion on it.

Great!

For your convenience, here is direct link to express your thoughts regarding this matter: Module System Design

[0x647262]

Thoughts on #51:

I put some thought into the issue, and I don't think that having an array of hard coded search paths is the ideal solution to the problem (I'd be happy to elaborate more if need be). Instead of hard coded search paths, the user's home directory should be the primary path, followed by the path used as the installation prefix. This could be done at compile time or through system / user configuration files.

Thoughts on #35:

Assuming the project is able to maintain strict adherence to semver's versioning guidelines, work on that issue is pretty much cut out for you. I would make the argument that the simplest way to implement this would be to follow in Python's footsteps:

 + ls /usr/bin/python*
/usr/bin/python -> python3
/usr/bin/python-config -> python3-config
/usr/bin/python2 -> python2.7
/usr/bin/python2-config -> python2.7-config
/usr/bin/python2.7
/usr/bin/python2.7-config
/usr/bin/python3 -> python3.7
/usr/bin/python3-config -> python3.7-config
/usr/bin/python3.7
/usr/bin/python3.7-config -> python3.7m-config
/usr/bin/python3.7m
/usr/bin/python3.7m-config

Going a step further, an ngs binary with a newer major version could pass off the execution of a script to an older ngs major version (assuming it is installed). This would be akin to Python 3 automatically passing the execution of a Python 2 script off to the python2 interpreter.

[ilyash-b]

Thanks for the input. I'll get to process it some day. Hopefully in the near future.