Conversation
balat
force-pushed
the
modernize
branch
4 times, most recently
from
efac8a4 to
8fd20d2
Compare
balat
force-pushed
the
modernize
branch
2 times, most recently
from
f952e36 to
a5a6354
Compare
Have [eliom-distillery] scan the [eliom-templates/] subdirectory of every installed ocamlfind package, so that third-party packages can ship distillery templates simply by installing files under [lib/<package>/eliom-templates/<name>/]. Also rename the in-tree template source dir from [pkg/distillery/templates/] to [pkg/distillery/eliom-templates/] for consistency.
Pure file renames, no content changes. For example: eliom_service.server.ml → service.server.ml eliom_content.eliom → content.eliom Files NOT renamed (name conflicts with Stdlib/external libs): eliom_form (conflicts with Js_of_ocaml.Form) eliom_lazy (conflicts with Stdlib.Lazy) eliom_react (conflicts with react library) eliom_uri (conflicts with uri library) Internal modules also kept unchanged: eliom_common, eliom_types, eliom_runtime, *_base, *_core, etc. This commit does not compile: reference updates follow.
Update all internal references from Eliom_xxx to the new short names. For example: Eliom_service.create → Service.create Eliom_parameter.int → Parameter.int References updated in: - Renamed source files (74 files) - Internal modules (eliom_common, eliommod_*, etc.) - PPX code (ppx_eliom_server.ml, ppx_eliom_utils.ml) References NOT changed (modules not renamed): Eliom_form, Eliom_lazy, Eliom_react, Eliom_uri Eliom_common, Eliom_runtime, Eliom_types, and all *_base/*_core modules
Create/update the Eliom module as the primary entry point: Eliom.Service, Eliom.Registration, Eliom.Content, etc. Modules with name conflicts use the old names: Eliom.Form = Eliom_form (Js_of_ocaml.Form conflict) Eliom.Lazy = Eliom_lazy (Stdlib.Lazy conflict) Eliom.React = Eliom_react (react library conflict) Eliom.Uri = Eliom_uri (uri library conflict) Create client-side Eliom module (previously server-only). Update dune: modules_without_implementation for renamed sig modules. Regenerate dune.server and dune.client.
Provide backward-compatible module names (Eliom_service, etc.) in separate libraries for existing code that hasn't migrated to the new Eliom.Service style. Usage: add eliom.compat.server (or .client) as a library dependency. These libraries are intended to be deprecated and eventually removed once downstream code has migrated. Server: 22 compat modules (16 .ml + 6 sig-only .mli) Client: 19 compat modules (12 .ml + 7 sig-only .mli)
Add Eliom_content, Eliom_cscache, Eliom_shared, Eliom_shared_content, and Eliom_tools to the compat libraries. These were missing because the duplicate .eliom files were removed in the previous cleanup.
Add eliom.compat.server and eliom.compat.client as library dependencies so the template continues to work with the old Eliom_xxx module names.
Replace old-style module names with the new namespace: Eliom_service.create → Eliom.Service.create Eliom_registration.App → Eliom.Registration.App Eliom_content.Html.F → Eliom.Content.Html.F etc. Remove eliom.compat.server/.client dependencies from the template.
- Migrate to Eliom.Service style module names - Rename PROJECT_NAME_main.eliom → PROJECT_NAME_server.eliom (executables: testapp_server.bc, testapp_server.exe) - Update Makefile.app targets accordingly
- Eliom_xxx → Eliom.Xxx in source files
- api.odocl: use new short module names - indexdoc: update documented module list - filelist.ml: update module list for packaging - _tags: disable warning 34 (OCaml 5.4), add logs.browser package
Define a named module type Content.Html.T (built from Tyxml's Html_sigs.Make(Xml)(Svg.F.Raw').T plus Eliom's LINKS_AND_FORMS) and use it as the parameter signature of Tools.Make instead of [module type of Content.Html.F]. Avoids the OCaml strengthening bug that triggers when [module type of] captures wrapped module paths through an alias (see ia-reports/2026-04-ocaml-wrapped-mtof-bug.md).
Use dune's [(wrapped (module_name Eliom))] feature to expose the public modules as [Eliom.Service], [Eliom.Content], [Eliom.Client], ... instead of the historical flat [Eliom_xxx] names. Update PPX client and dune configuration accordingly.
The module was incorrectly left with its old name despite being visible to users via PPX-generated type annotations. Also rename the local Client_value module in eliom_client_core.client.ml to Client_value_registry to avoid shadowing.
Accessible as Eliom.Syntax via wrapping. Used by the PPX in generated code (Eliom.Syntax.client_value, Eliom.Syntax.to_poly, etc.)
ppx_eliom_client.ml generates code referencing Eliom_client_core. With wrapping, this must be Eliom.Eliom_client_core for user code. Use eliom_expr to conditionally prefix with Eliom. when not -internal.
The PPX generates Eliom.Syntax.to_poly in user code, but the function was missing from the Syntax module (it was only in Lib.to_poly).
Visible to users via PPX-generated code (register_client_closure, open_client_section, close_server_section, get_escaped_value).
…odules The injection expression was hardcoded as Client_core.Syntax_helpers.get_injection instead of going through eliom_expr which prepends Eliom. when not in -internal mode.
Breaking change: Eliom.run is now Eliom.App.run due to module wrapping. The auto-generated wrapper module cannot contain val declarations, so this cannot be covered by eliom-compat.
The old ocamlbuild-based doc system could not handle wrapped modules. New build/gen_wikidoc.sh script: - Uses dune-compiled .cmi files from _build/ - Creates short-name .cmi aliases (Bus.cmi -> include Eliom__Bus) so ocamldoc can resolve cross-references - Gets include paths from dune's merlin config - Generates wiki docs for both server and client Also: - Move eliom-compat to separate package to avoid odoc conflicts - Add -internal to ocamlbuild PPX invocations (for legacy build) - Update .odocl and .mllib with renamed modules
- Remove src/ocamlbuild/ (eliom.ocamlbuild plugin) - Remove pkg/ (topkg packaging system) - Remove build/build.ml, build/doc.ml, build/_tags (ocamlbuild config) - Remove src/_tags, README.build - Remove js_of_ocaml-ocamlbuild dependency from dune-project/opam - Clean up ocamlbuild references in comments The doc generation now uses build/gen_wikidoc.sh (previous commit). The distillery templates in pkg/distillery/ are preserved.
When -internal-prefix Os is passed, the client PPX strips the Os. wrapper prefix from type paths read from server .cmo files. This is needed for compiling wrapped libraries like ocsigen-start that depend on Eliom.
Accessible as Eliom.Common from user code.
- eliom_content_core -> content_core - eliom_content_ -> content_functor - eliom_parameter_base -> parameter_base - eliom_service_base -> service_base - eliom_route_base -> route_base - eliom_comet_base -> comet_base - eliom_common_base -> common_base - eliom_cookies_base -> cookies_base - eliom_lib_base -> lib_base - eliom_types_base -> types_base - eliom_types -> types - eliom_runtime -> runtime - eliom_error_pages -> error_pages - eliom_process -> process - eliom_client_base -> client_base - eliom_client_main -> client_main - eliommod -> mod_main - eliommod_xxx -> mod_xxx Kept with prefix (name conflicts): - eliom_react (react package) - eliom_lazy (Stdlib.Lazy) - eliom_uri (uri package) - eliom_form (Js_of_ocaml.Form)
Client_value, Common, Content.Html, Registration.App, etc.
Ocsigen_extensions -> Ocsigen.Extensions Ocsigen_request -> Ocsigen.Request Ocsigen_response -> Ocsigen.Response Ocsigen_lib -> Ocsigen_base.Lib Ocsigen_cache -> Ocsigen_base.Cache Ocsigen_header -> Ocsigen_http.Header etc.
Place all module sources in [src/lib/{server,client}/Eliom/] and
use dune's standard [(include_subdirs qualified)] + [(wrapped false)]
to expose them under the [Eliom.] namespace. This removes the
dependency on the custom [(wrapped (module_name ...))] dune
extension.
[gen_dune.ml] now passes [-internal] to [--as-pp] PPX invocations
and emits [(subdir Eliom ...)] rules. Mli-only modules
(*_sigs, wrap) are copied as [.ml] to avoid
[modules_without_implementation].
Use dune's standard install pattern:
(install
(package eliom)
(section lib_root)
(files
(glob_files_rec
(templates/<name>/* with_prefix eliom/templates/<name>))))
so the bundled templates (app.exe, app.lib, basic.ppx) land at
[lib/eliom/templates/<name>/]. Packages that ship their own
templates install them at the same standard location, where
eliom-distillery looks by default.
[ELIOM_DISTILLERY_PATH] is preserved as an extra search path.
[Syntax.is_site_available] was returning [true] as soon as ocsigenserver reported being in its initialisation phase, regardless of whether a sitedata had actually been pushed. This is wrong during cmxs/cma loading: the top-level [close_server_section] calls inserted by the PPX in modules like [Service_base] try to read [Reference.Volatile.get site_data], which calls [Common.get_current_sitedata] and crashes with [Eliom_site_information_not_available] when the stack is empty. The default sitedata is pushed by a top-level [let _ =] in [Mod_main]. With the dunified build + [(include_subdirs qualified)], modules are linked alphabetically, so [Service_base] is loaded before [Mod_main] and its top-level [close_server_section] sees an empty stack. Add [Common.has_current_sitedata] to expose the stack-emptiness predicate, and require it in [is_site_available] alongside the existing [during_initialisation] check.
Module namespace migration to Eliom.Xxx, eliom-compat package, Eliom.Content.Html.T, distillery template install path, ocsigen-dune-rules integration, fix for is_site_available.
Eliom_uri header now mentions Eliom.Eliom_uri (its qualified name under the wrapping). Same for the cross-reference in form_sigs.shared.mli.
The Eliom_ prefix on the four legacy exceptions was redundant since they live under the Eliom.Common namespace (Eliom.Common.Eliom_site_information_not_available was visibly silly). - Common_base.Eliom_site_information_not_available → Site_information_not_available - Common.Eliom_do_redirection → Do_redirection - Common.Eliom_do_half_xhr_redirection → Do_half_xhr_redirection - Request_info (client) Eliom_no_raw_post_data_on_client → No_raw_post_data_on_client The first three are exposed in the mli; their legacy names are kept as backwards-compatible aliases (exception X = Y) so user code that catches the old names continues to work. The fourth was internal (not in any .mli), so the alias was dropped. Internal references to the legacy names are still in place; they will be migrated in a follow-up commit.
Update all internal references that previously raised or pattern-matched [Common.Eliom_X] to use the new short forms [Common.Site_information_not_available], [Common.Do_redirection], [Common.Do_half_xhr_redirection]. Behaviour is unchanged because the legacy names are aliases of the new ones.
Cross-references to {!Common.Eliom_site_information_not_available} in
service.server.mli, state.server.mli, config.server.mli,
request_info.server.mli, reference.server.mli, registration.server.mli
now point to the new {!Common.Site_information_not_available}.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
eliom_prefix (e.g.,eliom_service.server.ml→service.server.ml)Eliomwrapper module as the primary entry point:Eliom.Service,Eliom.Content, etc.eliom.compat.server/eliom.compat.clientlibraries providing backward-compatibleEliom_service,Eliom_registration, etc. namesModules not renamed (name conflicts)
eliom_formJs_of_ocaml.Formeliom_lazyStdlib.Lazyeliom_reactreactlibraryeliom_uriurilibraryThese are accessible as
Eliom.Form,Eliom.Lazy,Eliom.React,Eliom.Urithrough the wrapper module.Migration guide
New code:
Existing code (with eliom.compat):
Add
eliom.compat.server(or.client) to your dune libraries — the oldEliom_service,Eliom_registration, etc. names continue to work.Known limitations
(wrapped true)in user projects does not work with Eliom's client/server PPX (module identity mismatch between server lib and client executable). Templates use(wrapped false).Test plan
dune build @checkpassesdune fmtpasseseliom-distillery -template app.exegenerates and builds correctlyeliom-distillery -template app.libgenerates and builds correctly🤖 Generated with Claude Code