[postgis-devel] address standardizer: core or extra?

[Stephen Woodbridge]

Regina,

I think the main point the Greg is making is that the cmake command by 
default should require all the dependencies of a "standard" release and 
that it should fail if any of them are missing.

Then if someone wants to exclude a dependency and the features that 
depend on it that they can options to cmake like:

-DWITH_SFCGAL=no -DWITH_GEOS=no -DWITH_PCRE=no

or for optional or experimental features

-DWITH_<feature1>=yes -DWITH_<feature2>=yes

Or whatever. So by default every thing gets included for a "standard" 
release build and if you want to not include something it needs to be 
done explicitly.

Greg, correct me if I misunderstood.

-Steve

On 12/15/2015 11:13 AM, Paragon Corporation wrote:
> Greg and Steve,
>
> I think SFCGAL and GEOS are also things that get used if picked up.  I haven't tried a disable to verify it works.  Are you saying that isn't sufficient?
> On windows I pass everything in as a parameter since I never have the core dependencies in my environment path.
>
> As Steve said we plan to make this a core piece of our upcoming development and it is already used an optional feature for tiger geocoder, so we would prefer you consider it as a key part of PostGIS, especially since it's dependencies aren't too heavy.
>
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Stephen Woodbridge
> Sent: Monday, December 14, 2015 8:56 PM
> To: postgis-devel at lists.osgeo.org
> Subject: Re: [postgis-devel] address standardizer: core or extra?
>
> Hi Greg,
>
> I think this should get fixed by adding the dependency. While is has not be discussed on the list, the address standardizer will be an essential part of the geocoder rewrite that Regina and I will be tackling in 2016, to make the geocoder work with more data sets then just Tiger data. For example, I have written a geocoder using the address standardizer the works with both Tiger data and Navteq data and could work with other data sets also. The design and ideas I have implemented will be deployed in the rewrite.
>
> Ans I agree, things should not magically come or go based on the build environment, they should be explicitly configured and consistent from version to version.
>
> My 2c anyway,
>     -Steve
>
> On 12/14/2015 8:05 PM, Greg Troxel wrote:
>>
>> I just updated pkgsrc to 2.2.0.  While doing that, I noticed that the
>> address standardizer got built, when it hadn't before (even with my
>> draft 2.2.0 package).  I think this is because pcre became installed,
>> even though it wasn't in the dependency list.  So I forced it off to
>> be able to deal with the issue separately.
>>
>> I have three thoughts about this:
>>
>>     As a packager, I don't like things being automatically included or not
>>     based on dependencies.  They should be on or off, per --disable-foo,
>>     with some default, and if on fail noisily without the dependency.  The
>>     reason is to have repeatable builds that aren't influenced by the
>>     undocumented parts of the build environment.  I realize this is
>>     perhaps more difficult for users, although I'm not sure they are well
>>     served by optional components coming and going without noticing.
>>
>>     I don't know whether to leave this forced off, or to add the required
>>     dependencies and insist that it be built.  I don't really want to make
>>     a split package to hold this.  So I wonder if this is something that
>>     people consider part of postgis (i.e., is postgis without it broken?),
>>     or is it something that a few people want but is not really core.
>>
>>     Does this belong in postgis, or should it be seperate?  Or maybe
>>     separate but in the tarball (so that you build it from a subdir,
>>     assuming postgis is already installed).
>>
>>
>> Given that I've seen very little discussion on the list, I tend to
>> think it's not core.
>>
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus