Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get a (non cygwin) windows story at the API level #127

Closed
dbuenzli opened this issue Nov 18, 2014 · 5 comments
Closed

Get a (non cygwin) windows story at the API level #127

dbuenzli opened this issue Nov 18, 2014 · 5 comments

Comments

@dbuenzli
Copy link
Collaborator

First I think it would be a shame to propose a new build system without having a clear strategy on that topic. We may not get to it immediately but at least we should pave the way. There are two
different issues that need to be dealt with 1) Make sure the API allows us to express things in a portable way. 2) Having a driver that is actually able to run on windows to build a project. I focus on 1).

Given the new configuration API I don't think this should be too hard, and if the user doesn't do crazy things we could guarantee him that he gets a portable build system. There are a few things to sort out though.

  1. Utility configuration. How must utility names be looked up (extension business) when they are not explicitlely provided on the command line. Update the default configuration keys in Conf accordingly. Maybe also provide a combinator for that.
  2. Built-in build actions. Deal with Windows build artefact extensions (.exe, etc.), correctly cf. the ext_*, variables of ocamlc config.
  3. Paths. These are now abstracted in the system in the Path module and used pervasively. Verify that we do the right thing. One thing I don't get is how to handle absolute paths on windows.
  4. Build and non build command invocation. Sort out quotes/non quotes. Sort out what we (should) do ? Sys.command or Unix.create_process ?
  5. Flag non portable built-in system utility keys (none at the moment IIRC). Test the portable invocations provided in the Acmd module.
@dbuenzli
Copy link
Collaborator Author

Also a decent cmd.exe environment can be setup without to much trouble for testing using virtualbox, the vms here and ocp-win.

@rgrinberg
Copy link

Assemblage is a build system? I thought assemblage would be build system agnostic.

@dbuenzli
Copy link
Collaborator Author

The Assemblage API that allows you to describe your project exposes a build system model. What to do with this model is up to drivers that consume the project description.

@rgrinberg
Copy link

OK, Phew. Awesome! Keep up the good work.

@dbuenzli
Copy link
Collaborator Author

  1. There is also the build product suffixes which it seems can be trickier than I thought. See Wrong definition of extensions on Windows/Cygwin dbuenzli/topkg#11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants