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

"flexlink -install" to compile its own runtime objects #46

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

alainfrisch
Copy link
Collaborator

As discussed with @dra27, the idea is to let flexlink creates its own object files (flexdll_{initer_,}CHAIN.{obj,o}`). The following options are added to flexink:

  • -install : ask flexlink to compile the two objects files for the selected -chain and put them in the directory specified by -o.

  • -cc-prefix <PREFIX>: a string to be prepended to all tools of the selected toolchain; this can be used for gcc (mingw/cygwin) to specify an actual prefix such as i686-w64-mingw32- (defaults are used for those toolchains) and for cl (msvc) to specify an explicit directory (typically to select the 64-bit cl.exe even though it is not currently in the path). This option is used in the build system itself, but it should not be required by external users; they are likely to set up the path to find the correct cl.exe.

  • -runtime-objects <DIR>: specify the directory where runtime objects should be looked up.

@dra27 : please comment!

@dra27
Copy link
Member

dra27 commented Oct 25, 2017

The principle behind this looks fine, though it would at present break bootstrapping flexdll in OCaml. It's only a small piece of duplication, but it would be better for the Makefile still to build the C objects "by hand" (since this is what the OCaml flexdll target does and is also what the opam flexdll package will do). That would leave flexlink -install as the recommended way for building OCaml when you download a binary distribution, while also allowing the possibility of building without any binary tools to begin with.

Would you be happy to defer this until after 4.06.0 (so release 0.37 now)? The other thoughts I have:

  • It would be quite neat if flexlink embedded the C sources (so if they're quickly munged into an ML file during the build) - we could do the same thing with the default manifests
  • With this new install mechanism, it would also be good to get the object files installed to $(OCAMLLIB)/flexdll - which is where the bootstrapped version installs them. That's good for a lot of reasons, though it also means we should think about where the user should be required to put flexdll.h and how that would be communicated to OCaml. It requires changes in OCaml for both building methods, so that would clearly be for 4.07.0

@alainfrisch
Copy link
Collaborator Author

All good points, thanks! Delaying to after 0.37.

@alainfrisch
Copy link
Collaborator Author

I still suggest to install sources of support files in the binary distrib (dfd6212). Do you agree?

@dra27
Copy link
Member

dra27 commented Oct 25, 2017

I hadn't properly registered that, sorry - actually, with this flag, I'm kind of wondering if there needs to be object files in the binary distribution at all? FlexDLL obviously makes no sense as a package without a compiler, so why not just package up flexlink.exe and always require flexlink -install?

That's related to my suggestion of shifting towards always installing the objects with the application (i.e. OCaml - or in an arch-specific folder for the Cygwin/MSYS packages). Not keeping them with flexlink.exe also neatly solves the problem of wanting to have msvc objects compiled for pre- and post-VS2015.

@alainfrisch
Copy link
Collaborator Author

I'm kind of wondering if there needs to be object files in the binary distribution at all

Of course we could drop them altogether, but keeping them allows for a smoother transition. One can tell people to upgrade to, say, flexdll 0.38, and it will work even if they have e.g. older versions of OCaml still around.

The official instructions will likely be to use flexlink -install, but breaking compatibility does not seem necessary.

@dra27 dra27 mentioned this pull request Nov 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants