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

Automatic translation of object files in install stanzas for MSVC #1247

Open
dra27 opened this issue Sep 10, 2018 · 5 comments
Open

Automatic translation of object files in install stanzas for MSVC #1247

dra27 opened this issue Sep 10, 2018 · 5 comments
Labels

Comments

@dra27
Copy link
Member

dra27 commented Sep 10, 2018

Related: #690, #962, #1189

IIRC Dune automatically adds .exe to filenames when installing executables for Windows contexts. In addition to the support for variables in the referenced PRs, I'm wondering if it would be better for Dune to perform automatic conversion of items ending .o to .obj and .a to .lib for contexts using the Microsoft C compiler.

There might want to be some kind of syntax or semantics which prevents this kind of translation for very special cases (for example FlexDLL) where you might manipulate both .o and .obj files in the same place. However, for 99% of cases, writing .o in a dune is not portable.

@ghost
Copy link

ghost commented Sep 10, 2018

I wondered about this as well. It would definitely be easier for Linux programmers. However, I wonder how intuitive it would be for others, such as OSX programmers as I believe the extensions are already different.

@dra27
Copy link
Member Author

dra27 commented Sep 10, 2018

I didn’t know that - what’s the extension on macOS?

@ghost
Copy link

ghost commented Sep 11, 2018

I think there are several possible choices, but I'm not sure. Maybe @rgrinberg or @avsm know more.

What about windows users BTW? Will it be clear to them that they should write .o?

@rgrinberg
Copy link
Member

Extensions on OSX seems Unix like to me:

ext_exe: 
ext_obj: .o
ext_asm: .s
ext_lib: .a
ext_dll: .so

I'm wondering if we should simply start with warning the user when they use these unportable extensions. I'm not sure if the automatic translation in rules is very intuitive.

@avsm
Copy link
Member

avsm commented Sep 11, 2018

Only difference on osx is that there are special frameworks and .dylib extensions, but those are only as a result of explicit invocations. The rest is quite similar to Linux

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

No branches or pull requests

3 participants