Hello! + Any interest in CMake?

[Ian Mackenzie]

Hello! Just stumbled on Wren yesterday (via the bytecode chapter in Game Programming Patterns) and really liked the design. I have long wanted to find a nice, clean, easily embeddable language I can use in an open-source C++ CAD library I'm working on and I've always found Lua's syntax awkward - Wren seems to fit the bill perfectly. I'm also quite excited about the embedder-controlled import resolution system - I think there are some really cool possibilities there with doing automatic dependency fetching (kind of like Groovy's Grape).

I'd certainly like to help out any way I can - to start, is there any interest in having a CMake build option for Wren? I've really liked it on my own projects, so I'd be happy to take a crack at setting one up for Wren (I took a look at the makefile and wren.mk and everything seems fairly doable).

Either way, I'll probably start playing around with using the embedding API - any particularly dark corners there I should know about/stay away from?

[Bob Nystrom]

On Thu, Mar 19, 2015 at 2:58 PM, Ian Mackenzie <ian.e.m...@gmail.com> wrote:

Hello! Just stumbled on Wren yesterday (via the bytecode chapter in Game Programming Patterns) and really liked the design. I have long wanted to find a nice, clean, easily embeddable language I can use in an open-source C++ CAD library I'm working on and I've always found Lua's syntax awkward - Wren seems to fit the bill perfectly.

\o/

 

I'm also quite excited about the embedder-controlled import resolution system - I think there are some really cool possibilities there with doing automatic dependency fetching (kind of like Groovy's Grape).

I'd certainly like to help out any way I can - to start, is there any interest in having a CMake build option for Wren?

I thought about it when I initially set up the project. Trying to find the simplest way to manage the builds for a cross-platform C program is suprisingly tricky. Most meta-build systems (autoconf, gyp, etc.) see more complex than the problem they're trying to solve to me. These days, I figure you can cover 99% of the world by just maintaining a Makefile and a VS proj.

At the same time, a lot of people do seem to use CMake. What advantages do you see it adding?

 

Either way, I'll probably start playing around with using the embedding API - any particularly dark corners there I should know about/stay away from?

The embedding API is probably all dark corners at this point since it hasn't been battle-tested much (well, at all), but this is hugely important for Wren and I would be delighted to have you beat on it and see what breaks. If (when) you run into issues, I am highly motivated to fix them.

Cheers!

- bob

[Ian Mackenzie]

I thought about it when I initially set up the project. Trying to find the simplest way to manage the builds for a cross-platform C program is suprisingly tricky. Most meta-build systems (autoconf, gyp, etc.) see more complex than the problem they're trying to solve to me. These days, I figure you can cover 99% of the world by just maintaining a Makefile and a VS proj.

At the same time, a lot of people do seem to use CMake. What advantages do you see it adding?

Well, the immediate reason was that Visual Studio 2012 is the version I happen to have installed right now on my home computer, and I always get a bit nervous about having multiple versions of VS on the same machine (it *should* work, but I've been bitten in the past by installers/uninstaller glitches) so I didn't really want to install VS 2013. CMake makes it easy to generate solutions for whatever version of Visual Studio you happen to have lying around.

A few more general advantages:

• Only have to maintain one official set of build files for all platforms/compiler versions. I never quite trust projects that have a 'Windows' subfolder somewhere with VS solution files that may or may not work or be up to date - I appreciated that you were honest that the Makefile was the only 'official' method =).
• CMake provides a pretty nice, consistent way to set build options - it's easy to add variables (with docstrings) which can either be set at the command line, through ccmake (ncurses-based UI) or the CMake GUI. (It's pretty nice to fire up the CMake GUI and have it present you with a bunch of BUILD_STATIC_LIBS, INCLUDE_ICU_SUPPORT etc. variables with checkboxes beside them when you're trying to figure out how to configure and build somebody else's library!)
• CMake includes some pretty comprehensive platform introspection built in - check for Linux/Mac/Windows/MinGW/Cygwin, 32-bit vs. 64-bit etc.

There are lots of other nice CMake features ('cmake -E' mode for cross-platform cp/mv/rm/tar/md5 etc. utilities, ability to add custom build steps if necessary, good support for handling stuff like __declspec(dllexport) crap on Windows) but I think fundamentally what it comes down to is that I've always found CMake-based projects to be quite pleasant to set up, and third-party libraries using CMake to be quite easy to configure and build. Although to be fair I spend most of my coding time at work using Visual Studio, and for the Windows/VS ecosystem perhaps CMake is just the best of a bad lot.

 

The embedding API is probably all dark corners at this point since it hasn't been battle-tested much (well, at all), but this is hugely important for Wren and I would be delighted to have you beat on it and see what breaks. If (when) you run into issues, I am highly motivated to fix them.

=) I will start giving it a try soon. One thing I noticed was that I couldn't see an easy way to handle nested relative module imports since the embedder has no easy way of knowing which module a load-module request originated from - I might add a feature request with some ideas on GitHub after playing around with things a bit.

[Michel Hermier]

Hi,
From my previous projects there is at least on issue to be aware of with cmake.
Afaik you can't make static and dynamic builds at the same time. It can be problematic if you want modules as a .so while generating a vm as a .a on unix.
For the rest you can pretty do all the same.

--
You received this message because you are subscribed to the Google Groups "Wren" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wren-lang+...@googlegroups.com.
To post to this group, send email to wren...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wren-lang/63fca201-5e21-4f93-a678-943bc0bd83f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bob Nystrom]

On Wed, Mar 25, 2015 at 10:42 PM, Ian Mackenzie <ian.e.m...@gmail.com> wrote:

I thought about it when I initially set up the project. Trying to find the simplest way to manage the builds for a cross-platform C program is suprisingly tricky. Most meta-build systems (autoconf, gyp, etc.) see more complex than the problem they're trying to solve to me. These days, I figure you can cover 99% of the world by just maintaining a Makefile and a VS proj.

At the same time, a lot of people do seem to use CMake. What advantages do you see it adding?

Well, the immediate reason was that Visual Studio 2012 is the version I happen to have installed right now on my home computer, and I always get a bit nervous about having multiple versions of VS on the same machine (it *should* work, but I've been bitten in the past by installers/uninstaller glitches) so I didn't really want to install VS 2013.

For what it's worth, at my previous job I routinely had a few versions of VS installed and often even running concurrently without any problems.

 

CMake makes it easy to generate solutions for whatever version of Visual Studio you happen to have lying around.

A few more general advantages:

• Only have to maintain one official set of build files for all platforms/compiler versions. I never quite trust projects that have a 'Windows' subfolder somewhere with VS solution files that may or may not work or be up to date - I appreciated that you were honest that the Makefile was the only 'official' method =).

Yeah, this is nice. Though, even so, you still have to test the project/makefiles CMake generates, and you can still run into platform-specific issues on them.

(The hand-authored makefile has the same problem at a smaller scale. Even though it's a single makefile for Mac and Linux, it still has sections that are specific to each.)

• CMake provides a pretty nice, consistent way to set build options - it's easy to add variables (with docstrings) which can either be set at the command line, through ccmake (ncurses-based UI) or the CMake GUI. (It's pretty nice to fire up the CMake GUI and have it present you with a bunch of BUILD_STATIC_LIBS, INCLUDE_ICU_SUPPORT etc. variables with checkboxes beside them when you're trying to figure out how to configure and build somebody else's library!)
• CMake includes some pretty comprehensive platform introspection built in - check for Linux/Mac/Windows/MinGW/Cygwin, 32-bit vs. 64-bit etc.

There are lots of other nice CMake features ('cmake -E' mode for cross-platform cp/mv/rm/tar/md5 etc. utilities, ability to add custom build steps if necessary, good support for handling stuff like __declspec(dllexport) crap on Windows) but I think fundamentally what it comes down to is that I've always found CMake-based projects to be quite pleasant to set up, and third-party libraries using CMake to be quite easy to configure and build. Although to be fair I spend most of my coding time at work using Visual Studio, and for the Windows/VS ecosystem perhaps CMake is just the best of a bad lot.

One thing I try to keep in mind is that most users of Wren will likely use it directly from source. Anyone whose using the CLI that comes with Wren of course needs to build it directly. But if you're embedding Wren in your own application, my hunch is people as likely to just drop the whole src/ directory into their project as they are to build it separately and link it in.

Given that, I'm really hesitant to add complexity to the build scripts because that's work anyone using Wren from source will have to duplicate. I try to push as much of that logic into the C code itself so that the source files work pretty much as-is when you toss them into their app.

If something like CMake starts to seem really valuable it makes me wonder if we're doing too much work in the build process to begin with?

One option is to just slap together a VS2012 solution for Wren from scratch. It should be pretty painless. That would get you up and running without having to switch IDEs or write a bunch of build scripts.

I'm open to revisiting CMake at some point, but there is a lot to be said for keeping things simple.

 

The embedding API is probably all dark corners at this point since it hasn't been battle-tested much (well, at all), but this is hugely important for Wren and I would be delighted to have you beat on it and see what breaks. If (when) you run into issues, I am highly motivated to fix them.

=) I will start giving it a try soon. One thing I noticed was that I couldn't see an easy way to handle nested relative module imports since the embedder has no easy way of knowing which module a load-module request originated from - I might add a feature request with some ideas on GitHub after playing around with things a bit.

Ah, yes! This is, strangely enough, a corner of programming languages I have a lot of experience with. I wrote the package manager for the Dart language so I've spent more of my life than I probably care to thinking about how imports should be located. What the CLI supports right now is super primitive just because I haven't put much time into it. Extending it to support something like relative imports would be good.

Cheers!

- bob

[Ian Mackenzie]

One thing I try to keep in mind is that most users of Wren will likely use it directly from source. Anyone whose using the CLI that comes with Wren of course needs to build it directly. But if you're embedding Wren in your own application, my hunch is people as likely to just drop the whole src/ directory into their project as they are to build it separately and link it in.

That's a good point, and I've actually started doing exactly that myself (I now have Wren compiling happily embedded within my own CMake build system). In that case, what are your thoughts on having an auto-generated amalgamation source file like the one suggested in this pull request? It doesn't initially save a lot of time over just dropping in the src/ directory, but it does make it easier to upgrade to new versions of Wren as they come out  - assuming the project that Wren is embedded into is under version control, dropping in a new amalgamation source file and header just means committing a file modification or two, while dropping in a new src/ directory could mean adding/removing files (and perhaps folders) from version control and from whatever build system is being used. I get around the first issue by including a .tar.gz of the entire Wren source tree in my own repository (so adding/removing/changing Wren source files will just show up in my repository as a single file modification to the .tar.gz) and then using CMake magic to unpack it at build time, but I still have to manually list out all the source files to compile (CMake does not have very good glob support).

 

Ah, yes! This is, strangely enough, a corner of programming languages I have a lot of experience with. I wrote the package manager for the Dart language so I've spent more of my life than I probably care to thinking about how imports should be located.

Yup, Dart is another language that I'm following. I actually did a proof of concept getting my CAD library working as a native Dart extension, and it's something I may well get back to in the future since I really like the Dart language and ecosystem (pub is great). Right now, though, I'm waiting to see a bit more activity on the 'server'/Dart VM side of things first as I'm really most interested in Dart as an alternative to Python/C#/Java for writing desktop scripts/applications - I understand from the Dart mailing list that some of this is coming with Fletch etc., but now I am getting off topic =)

[Bob Nystrom]

On Mon, Mar 30, 2015 at 9:12 AM, Ian Mackenzie <ian.e.m...@gmail.com> wrote:

One thing I try to keep in mind is that most users of Wren will likely use it directly from source. Anyone whose using the CLI that comes with Wren of course needs to build it directly. But if you're embedding Wren in your own application, my hunch is people as likely to just drop the whole src/ directory into their project as they are to build it separately and link it in.

That's a good point, and I've actually started doing exactly that myself (I now have Wren compiling happily embedded within my own CMake build system). In that case, what are your thoughts on having an auto-generated amalgamation source file like the one suggested in this pull request?

I like it! I don't think it's the most important thing in the world, but I'd be happy to support it if possible. :)

Cheers!

- bob