[Geotiff] NOT depending on CMAKE

Howard Butler howard at hobu.co
Wed Jul 30 14:18:35 EST 2014


Ben,

Following up on this so as to not drop it. I have adapted your patch and incorporated into svn trunk. I tweaked the CMake to leave the filenames alone but simply sanitized the struct names. http://trac.osgeo.org/geotiff/ticket/66#comment:1

> 	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.

I think it makes sense to not support INCODE with anything but CMake. It's a rare use case, and not the default for most.

Howard

On Jun 17, 2014, at 9:54 PM, rudahl at rsgis.net wrote:

> 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
> 	***************************************
> 
> 
> 
> _______________________________________________
> Geotiff mailing list
> Geotiff at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/geotiff



More information about the Geotiff mailing list