update to new Clang.jl

[visr]

Continues the work in #120.
I wasn't able yet to run the Clang.jl generator yet, so this just moves in the bindings from #120. Still needs some cleanup, but I'd like to get it working first.

Some constants that were present before seem to be missing, like

GDAL.jl/src/common.jl

Line 537 in d44dc73

const GDAL_OF_VECTOR = 0x04

And before we had

GDAL.jl/src/common.jl

Line 1168 in d44dc73

const OGRGeomFieldDefnHS = Cvoid

Which now became mutable struct OGRGeomFieldDefnHS end. Probably it looks like changing these settings may be able to help here.

# if true, opaque pointers in function arguments will be translated to `Ptr{Cvoid}`.
opaque_func_arg_as_PtrCvoid = false

# if true, opaque types are translated to `mutable struct` instead of `Cvoid`.
opaque_as_mutable_struct = true

Though it could also be due to some of the not-so-nice rewriting we did here.

cc @melonedo @Gnimuc

[visr]

Great, the two issues mentioned above were solved by integrating #122 from @melonedo in this branch. Now both the GDAL.jl and ArchGDAL.jl tests are passing on this branch.

I also rebased it on top of master and added the time_t workaround suggested in #122 (comment).

Only when I run wrap.jl, the amount of docstrings seems to be much less than when @melonedo runs it.

For instance this docstring vanished:

GDAL.jl/gen/GDAL.jl

Lines 38 to 53 in b54e657

	"""
	CPLGetConfigOption(const char * pszKey,
	const char * pszDefault) -> const char *
	Get the value of a configuration option.
	### Parameters
	* **pszKey**: the key of the option to retrieve
	* **pszDefault**: a default value if the key does not match existing defined options (may be NULL)
	### Returns
	the value associated to the key, or the default value if not found
	"""
	function cplgetconfigoption(arg1, arg2)
	aftercare(ccall((:CPLGetConfigOption, libgdal), Cstring, (Cstring, Cstring), arg1, arg2), false)
	end

GDAL.jl/src/GDAL.jl

Lines 36 to 39 in e93d3df

	function cplgetconfigoption(arg1, arg2)
	aftercare(ccall((:CPLGetConfigOption, libgdal), Cstring, (Cstring, Cstring), arg1, arg2), false)
	end

@melonedo if you run wrap.jl on this branch, do the docstrings come back? Is the issue perhaps due to differences in the doxygen.xml we use? I use this one currently, which should be generated with the same GDAL version that we currently wrap, 3.2.

doxygen.zip

Both however sometimes seem to have too many empty lines, like here between the parameters:

GDAL.jl/src/GDAL.jl

Lines 764 to 779 in e93d3df

	# typedef void ( * CPLVirtualMemCachePageCbk ) ( CPLVirtualMem * ctxt , size_t nOffset , void * pPageToFill , size_t nToFill , void * pUserData )
	"""
	Callback triggered when a still unmapped page of virtual memory is accessed. The callback has the responsibility of filling the page with relevant values
	### Parameters
	* `ctxt`: virtual memory handle.
	* `nOffset`: offset of the page in the memory mapping.
	* `pPageToFill`: address of the page to fill. Note that the address might be a temporary location, and not at [`CPLVirtualMemGetAddr`](@ref)() + nOffset.
	* `nToFill`: number of bytes of the page.
	* `pUserData`: user data that was passed to [`CPLVirtualMemNew`](@ref)().
	"""
	const CPLVirtualMemCachePageCbk = Ptr{Cvoid}

[melonedo]

You can run add_doc.jl to add the docstrings. Without this, you can only see documentation included in the headers. Now it's harder to simply inject docstrings, so I created a script to do it. Of course, that loses some comments about function pointers.

Parameters now has an empty line is because sometimes parameters may contain more than one paragraphs, in that case an empty line is necessary. I think I can improve the docstring generation here to only add empty lines when necessary.

[visr]

Ah of course, thanks. I missed that add_docs.jl was not run automatically. Now calling it from wrap.jl in e995f29.

Parameters now has an empty line is because sometimes parameters may contain more than one paragraphs, in that case an empty line is necessary. I think I can improve the docstring generation here to only add empty lines when necessary.

I understand. It's definitely not needed for merging this.