-
Notifications
You must be signed in to change notification settings - Fork 188
Do Not Install FreeTDS on Gem Installs #342
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
Comments
I think this is a fantastic idea. I've been toying with a similar idea off on a feature branch in my fork while debugging the various windows "cannot load tiny_tds" errors in the issue list. The resulting tiny_tds build process became much much simpler once 3rd party dependencies and MiniPortile were removed from the extension build's responsibilities. |
Do you think this might warrant a major version number change? While the intent of the issue does indeed match the the documentation it will very likely break builds which rely on automatic downloading of 3rd party dependencies. I ran into exactly this problem while experimenting with removing MiniPortile from the extension build at https://github.com/coderjoe/tiny_tds/tree/extension.build.experiment As an aside, if all goes well I might have something resembling a PR for this issue soon. :) |
Yes, I set the label to 1.2.
Sweet! I am working on building new Docker images for TinyTDS/Adapter baed on the new CTP1.3 |
I meant re:semver, something along the lines of 2.0.0. ;) |
Yea... I thought so :) for some reason I was kind of hoping to keep 1.x for the sake of FreeTDS version matching... but I guess that does not really matter. You are right, to avoid the semver 👮 we should go to 2.0. |
Ubuntu 16.04 gem install tiny_tds no work ;( |
The extension build currently downloads and installs sources for libiconv, openssl, and freetds regardless of architecture. This is at odds with the correct procedure of installing these sources via the OS package manager for the non-binary gem build. This commit begins to solve this problem in a few ways: 1. It moves the responsibiliy of managing the MiniPortile builds to a ports rake task 2. It removes all ports specific logic from the extension build save the ability to search the ports directories if they exist (to facilitate the binary gem) 3. It adds cross compilation targets for the ports rake tasks to assist in the creation of the binary gems. 4. It enhances the rake clobber list to include the ports directories. 5. It removes custom logic for ports directory names and moves back towards relying on the MiniPortile defaults as much as possible. Relates to issue #342
We now have v2.1.0pre1 and v2.1.0.pre2 which both solve this issue. Soon there will be a full v2.1.0 release. |
The extension build currently downloads and installs sources for libiconv, openssl, and freetds regardless of architecture. This is at odds with the correct procedure of installing these sources via the OS package manager for the non-binary gem build. This commit begins to solve this problem in a few ways: 1. It moves the responsibiliy of managing the MiniPortile builds to a ports rake task 2. It removes all ports specific logic from the extension build save the ability to search the ports directories if they exist (to facilitate the binary gem) 3. It adds cross compilation targets for the ports rake tasks to assist in the creation of the binary gems. 4. It enhances the rake clobber list to include the ports directories. 5. It removes custom logic for ports directory names and moves back towards relying on the MiniPortile defaults as much as possible. Relates to issue rails-sqlserver#342
Uh oh!
There was an error while loading. Please reload this page.
Using MiniPortile to configure & install Iconv, OpenSSL, and FreeTDS crosses the line into package manager territory. This system is setup for us to build static gems for Windows platforms only and is being accidentally relied on by some platforms and/or happenstantial users that do not have these shared libraries installed.
Dependencies like FreeTDS should be installed by users via their package manager of choice. As needed, it is the user's responsibility to make sure TinyTDS knows how to find and link to these shared libraries. By avoiding getting caught up in a package manager's game, we can avoid:
Related Issues:
"Cannot load such file -- tiny_tds/tiny_tds" (version 1.1.0, version 1.0.0 is OK) #330
The text was updated successfully, but these errors were encountered: