NOT depending on CMAKE

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

NOT depending on CMAKE

rudahl
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 [hidden email] Sat, 14 Jun 2014 12:00
        From: [hidden email]
        Subject: Geotiff Digest, Vol 104, Issue 2
        To: [hidden email]
        Reply-To: [hidden email]
        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: [hidden email]
        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:[hidden email]?subject=unsubscribe>
        List-Archive: <http://lists.maptools.org/pipermail/geotiff>
        List-Post: <mailto:[hidden email]>
        List-Help: <mailto:[hidden email]?subject=help>
        List-Subscribe: <http://lists.maptools.org/mailman/listinfo/geotiff>,
                <mailto:[hidden email]?subject=subscribe>
        Sender: [hidden email]
        Errors-To: [hidden email]
        X-UIDL: P?F!!X^l"!ae%"!143!!

        Send Geotiff mailing list submissions to
                [hidden email]

        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
                [hidden email]

        You can reach the person managing the list at
                [hidden email]

        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 <[hidden email]>
        Subject: [Geotiff] INCODE EPSGs
        To: [hidden email], [hidden email]
        Message-ID: <[hidden email]>
        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
        [hidden email]
        http://lists.maptools.org/mailman/listinfo/geotiff

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



_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

Re: NOT depending on CMAKE

Howard Butler-3
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, [hidden email] 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 [hidden email] Sat, 14 Jun 2014 12:00
> From: [hidden email]
> Subject: Geotiff Digest, Vol 104, Issue 2
> To: [hidden email]
> Reply-To: [hidden email]
> 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: [hidden email]
> 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:[hidden email]?subject=unsubscribe>
> List-Archive: <http://lists.maptools.org/pipermail/geotiff>
> List-Post: <mailto:[hidden email]>
> List-Help: <mailto:[hidden email]?subject=help>
> List-Subscribe: <http://lists.maptools.org/mailman/listinfo/geotiff>,
> <mailto:[hidden email]?subject=subscribe>
> Sender: [hidden email]
> Errors-To: [hidden email]
> X-UIDL: P?F!!X^l"!ae%"!143!!
>
> Send Geotiff mailing list submissions to
> [hidden email]
>
> 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
> [hidden email]
>
> You can reach the person managing the list at
> [hidden email]
>
> 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 <[hidden email]>
> Subject: [Geotiff] INCODE EPSGs
> To: [hidden email], [hidden email]
> Message-ID: <[hidden email]>
> 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
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/geotiff
>
> End of Geotiff Digest, Vol 104, Issue 2
> ***************************************
>
>
>
> _______________________________________________
> Geotiff mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/geotiff

_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff