-
-
Notifications
You must be signed in to change notification settings - Fork 360
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
Allow compilation without GD #4274
Comments
fix for raster layers show configured options in error message use agg equivalents for pc256
I agree with requiring recent versions of GD (or halting if only an old version is provided). However, I would have thought that "-DUSE_GD_GIF -DUSE_GD_PNG -DUSE_GD_JPEG" may still be necessary as not all formats are built into GD by default unless I'm mistaken. (Maybe all binary packagers include them, but if you build GD from source you may not want to go through the trouble of including all lib dependencies) |
@dmorissette I agree, USE_GD_JPEG et. al. are useful, and the fix I am preparing still uses them (c.f. for example 2e7c4b7#L1R514 ) We also have USE_GD_WBMP which isn't specially difficult to keep, however I see no compelling reason to keep supporting this format (who wants to create bmps, especially for the web ?) |
WBMP could be considered obsolete IMHO. I'm fine with modern GD only if any... Sent from my iPad On Apr 7, 2012, at 1:36 PM, Thomas Bonfortreply@reply.github.com wrote:
|
I've pushed the changes into master. autotests pass except for the parts that rely on GD:
|
Mapserver cannot be built without gd. I would like to change this, as GD isn't the cornerstone it used to be in the older days.
In the "bye-bye-gd" branch, I have added the USE_GD define that effectively disables GD support if mapserver is configure with --without-gd. I would like to take this one step further.
We have these gd defines sprinkled around in the code:
@sdlime : Are these still relevant with recent gd versions? From my experience, I have never seen a gd build that did not provide all of these. For GD_HAS_FTEX_XSHOW this would actually break all renderers for FOLLOW labels (i.e. it would disable follow labels in all renderers if GD does not support it).
I would suggest removing these defines, and maybe halting the configure script if the supplied GD version does not provide one of our needed features. GD releases from 7 years ago supported them, so I guess it's reasonable to rely on them today.
The text was updated successfully, but these errors were encountered: