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

Use TrackIR DLL with 64 suffix when compiling a 64-bit build #1352

Merged
merged 1 commit into from Jun 2, 2017

Conversation

Projects
None yet
3 participants
@asarium
Member

asarium commented May 18, 2017

This should make it possible to have both DLL version installed at the
same time without causing conflicts.

Combined with the new DLL, this will finally fix #974.

Use TrackIR DLL with 64 suffix when compiling a 64-bit build
This should make it possible to have both DLL version installed at the
same time without causing conflicts.

Combined with the new DLL, this will finally fix #974.

@asarium asarium added the bugfix label May 18, 2017

@asarium asarium added this to the Release 3.8 milestone May 18, 2017

@chief1983

This comment has been minimized.

Show comment
Hide comment
@chief1983

chief1983 May 18, 2017

Member

I am confused why this was needed, it looked like two people reported that they had the DLL working without the suffix added. We don't have suffixing for any of our other pre-built libraries, isn't it odd to do so in this case?

Member

chief1983 commented May 18, 2017

I am confused why this was needed, it looked like two people reported that they had the DLL working without the suffix added. We don't have suffixing for any of our other pre-built libraries, isn't it odd to do so in this case?

@asarium

This comment has been minimized.

Show comment
Hide comment
@asarium

asarium May 18, 2017

Member

I decided that this was a good idea since we load this library dynamically instead of linking to it at compile time. The other prebuilt libraries always have to be distributed alongside the executable but the TrackIR DLL can also be located in the current working directory when FSO tries to load it.

If the engine executable should ever be moved to individual folder for different versions then the other prebuilt libraries would also need to be moved into that folder. Since the TrackIR DLL is an optional component of FSO that is placed into the FS2 root folder we still need to support both DLL versions (32- and 64-bit) at the same time which means that the files need to have different names.

Member

asarium commented May 18, 2017

I decided that this was a good idea since we load this library dynamically instead of linking to it at compile time. The other prebuilt libraries always have to be distributed alongside the executable but the TrackIR DLL can also be located in the current working directory when FSO tries to load it.

If the engine executable should ever be moved to individual folder for different versions then the other prebuilt libraries would also need to be moved into that folder. Since the TrackIR DLL is an optional component of FSO that is placed into the FS2 root folder we still need to support both DLL versions (32- and 64-bit) at the same time which means that the files need to have different names.

@chief1983

This comment has been minimized.

Show comment
Hide comment
@chief1983

chief1983 May 18, 2017

Member

Ok thanks for clearing that up.

Member

chief1983 commented May 18, 2017

Ok thanks for clearing that up.

@chief1983

This comment has been minimized.

Show comment
Hide comment
@chief1983

chief1983 May 18, 2017

Member

Since you managed to have it compiling now, would there be any benefit to a recompile of the 32bit version on a newer compiler as well? And perhaps putting 32 in its name to match the pattern?

Member

chief1983 commented May 18, 2017

Since you managed to have it compiling now, would there be any benefit to a recompile of the 32bit version on a newer compiler as well? And perhaps putting 32 in its name to match the pattern?

@asarium

This comment has been minimized.

Show comment
Hide comment
@asarium

asarium May 18, 2017

Member

Putting 32 into the name would probably break too much to warrant the change but I could recompile the DLL with the same settings as the 64-bit DLL.

Member

asarium commented May 18, 2017

Putting 32 into the name would probably break too much to warrant the change but I could recompile the DLL with the same settings as the 64-bit DLL.

@chief1983

This comment has been minimized.

Show comment
Hide comment
@chief1983

chief1983 May 18, 2017

Member

I guess it didn't seem that way if adding support for the 64bit one only required this ifdef, figured we could migrate people to a new one with 32 in the name for 3.8 final, and release the pair together as a new bundle.

Member

chief1983 commented May 18, 2017

I guess it didn't seem that way if adding support for the 64bit one only required this ifdef, figured we could migrate people to a new one with 32 in the name for 3.8 final, and release the pair together as a new bundle.

@asarium

This comment has been minimized.

Show comment
Hide comment
@asarium

asarium May 28, 2017

Member

Changing the name of the existing DLL could break current installations for no good reason. If someone only uses the 32-bit FSO builds then the current DLL will continue to work fine so I don't see a good reason for chaning the name of the 32-bit bridge DLL.

The release post should probably include a warning to let people know that the 64-bit builds require a new TrackIR DLL.

Member

asarium commented May 28, 2017

Changing the name of the existing DLL could break current installations for no good reason. If someone only uses the 32-bit FSO builds then the current DLL will continue to work fine so I don't see a good reason for chaning the name of the 32-bit bridge DLL.

The release post should probably include a warning to let people know that the 64-bit builds require a new TrackIR DLL.

@The-E

The-E approved these changes Jun 2, 2017

@The-E The-E merged commit e6c6cc3 into scp-fs2open:master Jun 2, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@asarium asarium deleted the asarium:feature/trackIr64bit branch Jun 2, 2017

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