Fossil SCM
build.wiki: added a note about minimum emcc version and notes about using alternatives to Emscripten.
Commit
f7d53fa82af04a2e4e74b59d33765197e3fcd19c464bce89555cb2e2f2617712
Parent
7fcb462680ce63a…
1 file changed
+28
-3
+28
-3
| --- www/build.wiki | ||
| +++ www/build.wiki | ||
| @@ -564,12 +564,23 @@ | ||
| 564 | 564 | $ ls -la extsrc/pikchr.{js,wasm} |
| 565 | 565 | -rw-rw-r-- 1 stephan stephan 17263 Jun 8 03:59 extsrc/pikchr.js |
| 566 | 566 | -rw-rw-r-- 1 stephan stephan 97578 Jun 8 03:59 extsrc/pikchr.wasm |
| 567 | 567 | </code></pre> |
| 568 | 568 | |
| 569 | -Then run the normal build so that those files can be compiled in to | |
| 570 | -the fossil binary, accessible via the [/help?cmd=/builtin|/builtin page]: | |
| 569 | +<blockquote>Sidebar: if that fails with a message along the lines of: | |
| 570 | + | |
| 571 | +<pre><code>setting `EXPORTED_RUNTIME_METHODS` expects `<class 'list'>` but got `<class 'str'>`</code></pre> | |
| 572 | + | |
| 573 | +then the emcc being invoked is too old: emcc changed the format of | |
| 574 | +list-type arguments at some point. The required minimum version is | |
| 575 | +unknown, but any SDK version from May 2022 or later "should" (as of | |
| 576 | +this writing) suffice. Any older version may or may not work. | |
| 577 | +</blockquote> | |
| 578 | + | |
| 579 | +After that succeeds, we need to run the normal build so that those | |
| 580 | +generated files can be compiled in to the fossil binary, accessible | |
| 581 | +via the [/help?cmd=/builtin|/builtin page]: | |
| 571 | 582 | |
| 572 | 583 | <pre><code>$ make</code></pre> |
| 573 | 584 | |
| 574 | 585 | Before checking in those newly-built files, they need to be tested by |
| 575 | 586 | running the [/pikchrshow] page. If that page loads, the compilation |
| @@ -577,8 +588,22 @@ | ||
| 577 | 588 | the viewer). If it fails to load then the browser's dev tools console |
| 578 | 589 | likely provides at least a small hint (and <em>sometimes</em> a useful |
| 579 | 590 | hint) about the nature of the problem. Don't check those files in |
| 580 | 591 | until [/pikchrshow] runs, though! |
| 581 | 592 | |
| 582 | -Should pikchr's C interface ever changes, <tt>pikchr-worker.js</tt> | |
| 593 | +Should pikchr's C interface ever change, <tt>pikchr-worker.js</tt> | |
| 583 | 594 | will need to be updated to accommodate it, but such modification is |
| 584 | 595 | typically trivial. |
| 596 | + | |
| 597 | +<h3>8.1 Solutions other than Emscripten?</h3> | |
| 598 | + | |
| 599 | +Emscripten is not the only option for building C as WASM, but it | |
| 600 | +provides a complete toolchain which eliminates many other steps which | |
| 601 | +must otherwise be accounted for on a per-project basis. Despite its | |
| 602 | +convenience, it behooves us to explore other build options for the | |
| 603 | +sake of portability and avoiding what amounts to vendor lock-in. | |
| 604 | + | |
| 605 | +For later refererence, here are articles specifically covering | |
| 606 | +building WASM projects without using Emscripten: | |
| 607 | + | |
| 608 | + * [https://surma.dev/things/c-to-webassembly/] | |
| 609 | + * [https://schellcode.github.io/webassembly-without-emscripten] | |
| 585 | 610 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -564,12 +564,23 @@ | |
| 564 | $ ls -la extsrc/pikchr.{js,wasm} |
| 565 | -rw-rw-r-- 1 stephan stephan 17263 Jun 8 03:59 extsrc/pikchr.js |
| 566 | -rw-rw-r-- 1 stephan stephan 97578 Jun 8 03:59 extsrc/pikchr.wasm |
| 567 | </code></pre> |
| 568 | |
| 569 | Then run the normal build so that those files can be compiled in to |
| 570 | the fossil binary, accessible via the [/help?cmd=/builtin|/builtin page]: |
| 571 | |
| 572 | <pre><code>$ make</code></pre> |
| 573 | |
| 574 | Before checking in those newly-built files, they need to be tested by |
| 575 | running the [/pikchrshow] page. If that page loads, the compilation |
| @@ -577,8 +588,22 @@ | |
| 577 | the viewer). If it fails to load then the browser's dev tools console |
| 578 | likely provides at least a small hint (and <em>sometimes</em> a useful |
| 579 | hint) about the nature of the problem. Don't check those files in |
| 580 | until [/pikchrshow] runs, though! |
| 581 | |
| 582 | Should pikchr's C interface ever changes, <tt>pikchr-worker.js</tt> |
| 583 | will need to be updated to accommodate it, but such modification is |
| 584 | typically trivial. |
| 585 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -564,12 +564,23 @@ | |
| 564 | $ ls -la extsrc/pikchr.{js,wasm} |
| 565 | -rw-rw-r-- 1 stephan stephan 17263 Jun 8 03:59 extsrc/pikchr.js |
| 566 | -rw-rw-r-- 1 stephan stephan 97578 Jun 8 03:59 extsrc/pikchr.wasm |
| 567 | </code></pre> |
| 568 | |
| 569 | <blockquote>Sidebar: if that fails with a message along the lines of: |
| 570 | |
| 571 | <pre><code>setting `EXPORTED_RUNTIME_METHODS` expects `<class 'list'>` but got `<class 'str'>`</code></pre> |
| 572 | |
| 573 | then the emcc being invoked is too old: emcc changed the format of |
| 574 | list-type arguments at some point. The required minimum version is |
| 575 | unknown, but any SDK version from May 2022 or later "should" (as of |
| 576 | this writing) suffice. Any older version may or may not work. |
| 577 | </blockquote> |
| 578 | |
| 579 | After that succeeds, we need to run the normal build so that those |
| 580 | generated files can be compiled in to the fossil binary, accessible |
| 581 | via the [/help?cmd=/builtin|/builtin page]: |
| 582 | |
| 583 | <pre><code>$ make</code></pre> |
| 584 | |
| 585 | Before checking in those newly-built files, they need to be tested by |
| 586 | running the [/pikchrshow] page. If that page loads, the compilation |
| @@ -577,8 +588,22 @@ | |
| 588 | the viewer). If it fails to load then the browser's dev tools console |
| 589 | likely provides at least a small hint (and <em>sometimes</em> a useful |
| 590 | hint) about the nature of the problem. Don't check those files in |
| 591 | until [/pikchrshow] runs, though! |
| 592 | |
| 593 | Should pikchr's C interface ever change, <tt>pikchr-worker.js</tt> |
| 594 | will need to be updated to accommodate it, but such modification is |
| 595 | typically trivial. |
| 596 | |
| 597 | <h3>8.1 Solutions other than Emscripten?</h3> |
| 598 | |
| 599 | Emscripten is not the only option for building C as WASM, but it |
| 600 | provides a complete toolchain which eliminates many other steps which |
| 601 | must otherwise be accounted for on a per-project basis. Despite its |
| 602 | convenience, it behooves us to explore other build options for the |
| 603 | sake of portability and avoiding what amounts to vendor lock-in. |
| 604 | |
| 605 | For later refererence, here are articles specifically covering |
| 606 | building WASM projects without using Emscripten: |
| 607 | |
| 608 | * [https://surma.dev/things/c-to-webassembly/] |
| 609 | * [https://schellcode.github.io/webassembly-without-emscripten] |
| 610 |