[Geotiff] NOT depending on CMAKE

[rudahl at rsgis.net]

The problem with some of the comments in Benjamin Adler's note is that
in my experience, CMAKE is not reliably available. Sorry, I can't
remembe  specifics but there were a couple of environments where
I could not build CMAKE. As I recall, there were dependencies on
library code where my distros didn't have the required symbols.

Maybe I'm old fashioned, but I don't think that trying to build
a package should require me to debug the tool chain.

I did eventually find a way around my problem but not using CMAKE.
Since then I have avoided it .

Respectfully - Kurt

	From geotiff-request at lists.maptools.org Sat, 14 Jun 2014 12:00
	From: geotiff-request at lists.maptools.org
	Subject: Geotiff Digest, Vol 104, Issue 2
	To: geotiff at lists.maptools.org
	Reply-To: geotiff at lists.maptools.org
	Date: Sat, 14 Jun 2014 12:00:02 -0500
	MIME-Version: 1.0
	Content-Type: text/plain; charset="us-ascii"
	Content-Transfer-Encoding: 7bit
	X-BeenThere: geotiff at lists.maptools.org
	X-Mailman-Version: 2.1.9
	Precedence: list
	List-Id: GeoTIFF and libgeotiff discussion <geotiff.lists.maptools.org>
	List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/geotiff>,
		<mailto:geotiff-request at lists.maptools.org?subject=unsubscribe>
	List-Archive: <http://lists.maptools.org/pipermail/geotiff>
	List-Post: <mailto:geotiff at lists.maptools.org>
	List-Help: <mailto:geotiff-request at lists.maptools.org?subject=help>
	List-Subscribe: <http://lists.maptools.org/mailman/listinfo/geotiff>,
		<mailto:geotiff-request at lists.maptools.org?subject=subscribe>
	Sender: geotiff-bounces at lists.maptools.org
	Errors-To: geotiff-bounces at lists.maptools.org
	X-UIDL: P?F!!X^l"!ae%"!143!!

	Send Geotiff mailing list submissions to
		geotiff at lists.maptools.org

	To subscribe or unsubscribe via the World Wide Web, visit
		http://lists.maptools.org/mailman/listinfo/geotiff
	or, via email, send a message with subject or body 'help' to
		geotiff-request at lists.maptools.org

	You can reach the person managing the list at
		geotiff-owner at lists.maptools.org

	When replying, please edit your Subject line so it is more specific
	than "Re: Contents of Geotiff digest..."


	Today's Topics:

	   1. INCODE EPSGs (Benjamin Adler)


	----------------------------------------------------------------------

	Message: 1
	Date: Sat, 14 Jun 2014 13:55:29 +0000
	From: Benjamin Adler <benadler at gmx.net>
	Subject: [Geotiff] INCODE EPSGs
	To: warmerdam at pobox.com, geotiff at lists.maptools.org
	Message-ID: <539C5451.2080909 at gmx.net>
	Content-Type: text/plain; charset="iso-8859-1"

	Hello,

	I have built libgeotiff on windows (CMake, 64bit, msvc2012) and were 
	surprised about some EPSGs being includable INCODE, others not. So I 
	talked to Frank on IRC and thought I might come up with a patch to fix this.

	In my mind, the following things could be improved:

	  - in the csv/ subdir, a seemingly random subset of CSVs are converted 
	to .c using csv2c.py, others are not. So the releases contain redundant 
	data.

	  - csv2c.py only takes one parameter (the .csv) and creates the 
	c-source right next to it, just with a different extension. This seems 
	to follow the old building-in-source-tree idea of automake, which I 
	don't consider very elegant.

	  - csv2c.py fails to correctly convert *.override.csv files. This is 
	because the filename is part of the variable name in the resulting 
	c-source, e.g. converting "gcs.override.csv" results in "datafile_rows_t 
	gcs.override_row_1[]", and the dot doesn't make sense here. I suggest 
	naming those files without a dot, e.g. gcs_overrride.csv

	What the attached patch tries to do:

	  - change cvs2c.py so that it accepts an input and an output parameter.

	  - change CMakeLists.txt to let the user choose which csv files to 
	include in code. It will add buildrules to autogenerate .c from .csv 
	files and add them to the library target. This requires python for 
	csv2c.py. It will also generate an include file that replaces the 
	epsg-incode definitions found in cpl_csv_incode.c.

	  - change cpl_csv_incode.c to include the autogenerated include.

	I have tested this on windows and linux (ubuntu 13.10 64bit, cmake 
	version 2.8.11.2) and was able to happily inflate libgeotif from less 
	than 1 to more than 16MB (windows) by including all EPSG data in code :)

	I am not a cmake expert (in fact, BtbN from #cmake helped me a lot with 
	this, thank you!), not a c expert and not a geotiff expert. So please 
	have a thorough look at this before you commit.

	Not quite sure if it makes sense to keep using automake when CMake also 
	works, but there's one problem if you do: I removed the old/static epsg 
	definitions from cpl_csv_incode.c and replaced them with the 
	cmake-generated include. When using automake, this include doesn't exist.

	Frank, how can this be fixed? Maybe use -DAUTOMAKE and keep the old 
	definitios in cpl_csv_incode.c #ifdef'ed in? That's not really elegant, 
	and you'd still have to distribute those csv-c-sources, but I guess it 
	would work.

	Also, the automakefile needs to be updated to invoke cvs2c.py with a 
	second argument.

	Cheers,
	ben
	-------------- next part --------------
	A non-text attachment was scrubbed...
	Name: epsg_incode.patch
	Type: text/x-patch
	Size: 5369 bytes
	Desc: not available
	Url : http://lists.maptools.org/pipermail/geotiff/attachments/20140614/5136d0d6/attachment-0001.bin 

	------------------------------

	_______________________________________________
	Geotiff mailing list
	Geotiff at lists.maptools.org
	http://lists.maptools.org/mailman/listinfo/geotiff

	End of Geotiff Digest, Vol 104, Issue 2
	***************************************