[Geotiff] NOT depending on CMAKE
Howard Butler
howard at hobu.co
Wed Jul 30 12:18:35 PDT 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