-
Notifications
You must be signed in to change notification settings - Fork 52
macros in Build Scripts #78
Comments
i'm generally reluctant to add generic build scripts because they just delay the inevitable problem. if a dependency is not portable C code, you'll end up with difficult to maintain build steps no matter what. For example libuv probably wants to create a static lib, but how do you tell it to enable ubsan? you could pass a bunch of CFLAGS down there, but you'll just end up rewriting their build system anyway, so you might as well just add the cfiles. However, if you still feel like this is the better path, i'd suggest to just straight up copy what rust does. It's not great, but at least its flexible enough that it does allow a library to solve these issues. |
That is a great point. It is actually possible to achieve this now, without code change by using macros! I created an arbitrarily named file called using <unistd.h>::{ getcwd }
using <stdio.h>::{ stdout, fclose, sprintf }
using <stdlib.h>::{ system }
macro build() {
char mut cwd[65335];
char mut command[65335];
fclose(stdout);
getcwd(cwd, sizeof(cwd));
sprintf(command, "touch %s/foo", cwd);
system(command);
}
fn init() {
@build();
} |
wow thats really smart, i love it |
hell yeah, okay closing! |
actually, it doesnt let you add cobjects or ldflags to the linker. that's probably something you'll need. i guess we could expand the macro AST to add these. |
i.e. by adding a generic way to add things to cobjects, ldflags and cflags from regular statements https://github.com/zetzit/zz/blob/master/src/zz.pest#L295 then macro can expand to these statements. |
hmm, interesting! what would that look like? |
pp is also a good candidate to add this stuff to https://github.com/zetzit/zz/blob/master/src/zz.pest#L136 something like #LDFLAGS: -luv
struct uv {
...
} |
this is now implemented in #97 . it merely lacks support for macros to close this |
this is not closed. still lacking macro support to enable pkgconfig and other configuration tests |
Currently, there is no way to depend on a library or source code that needs to be built outside of the ZZ build process. Listing source files as
cobjects
is not enough when the library source may require the traditional ritual ofautoconf, configure, make, make install (with prefix)
.An example of this are the libuv bindings over here
When a consumer of this module uses it, it will break because there is no way to build the libuv submodule before the ZZ module is built.
@aep What are your thoughts on supporting build scripts? We could have a
[scripts]
section of thezz.toml
file similar to that of npm-scripts or something similar to Rust's Build Scripts.The text was updated successfully, but these errors were encountered: