Skip to content

Can not find the configure script #2

Open
sanabgr wants to merge 192 commits intomasterfrom
branch-6-0-stable
Open

Can not find the configure script #2
sanabgr wants to merge 192 commits intomasterfrom
branch-6-0-stable

Conversation

@sanabgr
Copy link
Copy Markdown

@sanabgr sanabgr commented Feb 2, 2023

Dear
I want to install gnuplot using cmakelist file , so I am using the following commands
CONFIGURE_COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/external/gnuplot/configure --prefix=${CMAKE_CURRENT_SOURCE_DIR}/external/gnuplot
BUILD_COMMAND make
In the readme it's mentioned that to install we use : ./configure but there is no configure script in the folder gnuplot?

Ethan A Merritt and others added 30 commits January 10, 2023 22:43
Polygons were being treated similarly to "with filledcurves", where
"empty" is silently converted to "solid" because for most filledcurves
modes there is no usable border so empty would otherwise mean invisible.

Arguably "with filledcurves closed" should also allow a true empty
fillstyle, but for that you can now use "with polygons" so I left it.
Newer gdlib versions do a much better job of antialiasing, but only
if truecolor is selected so that the library maintains an alpha channel.
On the other hand our previous workaround for bad antialiasing,
"set term png rounded", has become very slow.
Change the default to use the new antialiasing with butt linecaps.

The jpeg, gif, and sixel terminals also now default to "butt".
don't try to select or call it.
… border"

If you set a linecolor for an empty circle/polygon/ellipse this has the
effect of changing the border property.  I.e.
	set obj 1 fs empty
	set obj 1 lc "red"
is now equivalent to
	set obj 1 fs empty border lc "red"

This is a CHANGE.  Previously the default was "fs solid border -1 fc bgnd"
for circles and ellipses, "fc 'black'" for polygons.

Rectangles remain a separate case and are unchanged by this commit.
Rectangles have always been treated differently than other object types.
Old configuration message:
Check current directory for .gnuplot file - normally disabled for security reasons

This option has been disrecommended for a long time as a security hazard.
Addition of support for XDG directory conventions in version 5
would seem to make it even less necessary than before.
The LaTeX tutorial was based on old latex terminals that are no longer
supported. It was functionally replaced by a latex terminal demo
demo/latex_demo.tex.

The tutorial was already removed as a top level build target
by commit f623755.  Now it is not listed as a configure option.
Unfortunately snprintf can segfault if passed non-ascii bytes in a format
string, e.g. snprintf( out, n, "%<ff>2f", x)
We were already checking for illegal ascii characters;
now we check for non-ascii characters also.

Found by fuzzing input.
Several filters or smoothing operations replace the original plot->points
array with a new one holding the smoothed data points.

If they neglect to update the corresponding bookkeeping data in the header,
it could lead to memory corruption.  (plot->p_max, plot->varcolor, etc).
Call cp_extend, which gets it right, instead of simply doing
plot->points = alloc(...).

Affects grid_polar_data(), make_bins(), convex_hull().
…lcolor

The filled area of a filled curve is drawn first.
If the fillstyle has a border a separate call to plot_lines() is then made.
Polygons are the same.
But plot_lines() checks for variable color again and gets the fill color not
the border color.  Disable this check for plot styles filledcurves and polygons.
An iteration immediately following a definition in a plot or splot
command was not parsed.

Arguably this is not a reasonable thing to do anyhow, as it should be
	foo=1; plot for [i=1:N] ...
but it's fixable so fix it.

Bug #2580
Mostly just fixes column alignment of the configuration summary
Otherwise UNDEFINED points may leave uninitialized holes in the
coordinate structure, which valgrind flags as an error.
If key->title.font is set, key->font was ignored during key layout.
The key font was totally ignored for the purpose of 3D key layout.
Unlike the 2D case, this was true independent of key->title.font.
Anything other than "smooth path" is an error
I.e.
    Overview.html -> loc1.html
    Plotting_styles.html -> loc4508.html  or wherever it ends up being.

In particular this allows cross-references to the top level page for
plotting styles, as in "See `plotting styles`.".
The docs/doc2texi.el converter transforms the line starting
with "<3" into a Texinfo comment by inserting "@c " at the
beginning of the line (function d2t-get-terminals). However,
the input has not been converted to the Texinfo format yet,
so that function d2t-braces-atsigns, which is called later,
assumes that "@c" is real text and adds a @ in front of it.
As a consequence, one gets a line
  @@c <3 -- all terminal stuff is pulled from the .trm files
in the generated Texinfo file gnuplot.texi, and this line
will be rendered as
  @c <3 -- all terminal stuff is pulled from the .trm files
in the Info manual.
This patch makes doc2texi.el remove the "<3" line instead of
attempting to comment it out.
Modify the order of searching for libgd so that a user-supplied
DIR is tried first.
The system's pkgconfig file gdlib.pc is only searched if no DIR is given.
Use of a gdlib-config script has been deprecated upstream.

No change to the operation of
    configure --with-gd
    configure --with-gd=yes
    configure --with-gd=no
    configure --without-gd

Bug #2569
Make it a user option instead:
    set help {rows|columns}

This is clearly a per-user preference, not something that should be
a build-time option.  Why would you expect all end users to have the
same preference?
That is, NaN now triggers term->linetype(LT_NODRAW)
rather than term->set_color(BACKGROUND_COLOR).

I think this is clearly better if you are actually drawing lines.
If you are using it for solid fill I think the result is
terminal-dependent.  Some will not draw anything (good) and others
might use the "color" of LT_NODRAW which is background color
(not as good but the same as it was doing before).
It was treating this as a dash pattern with dots separated by
a lot of distance.  But it did draw the line, so those widely
space dots could appear in the rendered graph.

Now we convert all the component vector draws to moves,
so nothing is actually drawn.
Ethan A Merritt and others added 30 commits July 17, 2023 12:10
Re-word title so that "make gnuplot.texi" is happy.
gnuplot.pdf now depends on pdf_figures rather than figurestyle.

Retain built files (allterm.h allterm-ja.h) across "make clean".

It remains true that after unpacking the distribution tarball,
or after "make distclean" in the docs subdirectory,
you must do "make" or "make all" before trying to make only a
single target, e.g. "make gnuplot.pdf".
Note: requires C++  -std=c++17

Note: requires Qt6 compatibility module Core5Compat
	for class QTextCodec
		codecForLocale() codecForMib() fromUnicode() toUnicode()
	in order to support non-utf8 encodings (gnuplot's "set encoding").

	This is not entirely satisfactory, since there is apparently not
	a guarantee from Qt that the compatibility modules will continue
	to be available in the future.

./configure --with-qt=qt4  is still accepted but I no longer have
the Qt4 libraries installed to confirm that it works.
Calling add_udv_by_name() on a nonexistent variable has the side effect
of allocating a new variable which is then marked NOTDEFINED.
Calling instead get_udv_by_name() is cleaner.
Back-port the current stable sort code from 6.1, merging a series
of changes, fixes, and revisions into this single commit.

The qsort implementation in glibc is stable; i.e. elements that test
as equal are guaranteed to retain their origin order.
The relevance to gnuplot is that if either "pm3d depthorder" or
"set hidden3d" is used to render two surfaces with identical [x,y,z],
the first will be consistently occluded by the second.

However the qsort provided by BSD and macOS is not stable.
Those systems may provide mergesort as a stable alternative.

Other non-glibc platforms including mingw and Cygwin do not provide a stable sort.
On these platforms, identical surfaces sorted for either pm3d or hidden3d
are rendered inconsistently.  Any given quadrangle or line segment may
be rendered with the properties of either of the requested surfaces.

Gnuplot will now try to pick an appropriate stable sort if possible
and otherwise add code so that pm3d depth-sorting is stable.

./configure --with-stable-sort
     1) Use mergesort if the system provides it, otherwise qsort.
     2) If neither mergesort nor glibc's qsort is available
        add a sequence field to pm3d quadrangles to be used as a
	secondary sort key.
Refactor the colorbox code to support an alternative method for
rendering the color gradient.  If the terminal supports this mode,
the colorbox content is described as 1xN pixel array and rendered
using the term->image routine.
Problem: Some renderers (svg, everything on MacOS) use bilinear or
bicubic interpolation to smooth pixel arrays even if the wrapping
code specifically requests otherwise.

Solution: Add oversampling to the pixel gradient used for the colorbox.
This change should make the new method usable by additional terminals.

Thanks to Hiroki Motoyoshi for the oversampling code.

Thanks to Alexander Täschner for identifying accommodation
needed for incomplete support of c99 standard features in MSVC.

Rather than selecting the colorbox-as-image code for all terminals
that support term->image, make it depend on a terminal flag
    if ((term->flags & TERM_COLORBOX_IMAGE))

For now the flag is set by these terminals
	epscairo cairolatex pdfcairo qt
Since PostScript does not support transparency, gnuplot uses the
"with rgbalpha pixels" pixel-by-pixel emulation to handle the alpha
channel in images.  However pixmaps may have an alpha channel and
they bypass the general image processing by calling term->image()
directly.  This meant that the postscript terminal driver was getting
image data in mode IC_RGBA, which it did not support. Now it throws
away the alpha channel and treats the image as if it used mode IC_RGB.

Bug #2644
Up till now it has restored the linecolors, but did not touch the
linewidth, point or dash properties.  That was contrary to the
documented intent of the command, so arguably this change is a bugfix.
Nevertheless it is a change to the version 5 behavior.
Attempts to retrieve style information from the first vertex of a
size zero polygon caused memory access errors.
If a vertex of the polygon is very far out of bounds, the interpolation
routine intersect_polyedge_with_boundary() could return an incorrect
result due to integer overflow/wraparound.
Now we cast to (double) for this calculation.
but instead it was taken from "set style fill".
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.

6 participants