[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OF geometry] un-syncable with upstreeam

From: Philip Nienhuis
Subject: Re: [OF geometry] un-syncable with upstreeam
Date: Wed, 15 Aug 2018 13:03:36 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48

hi JuanPi,

Juan Pablo Carbajal wrote:
Hi Phillip, Of leaders, and maintainers,

I was trying to release geometry today. It is impossible! (well very
The problem is that from the beginning I made the mistake of trying to
convert the package to Octave and Of standards... wrong!

So I am inclined to:
1. Reduce the current geometry package to contain only our extensions
to matgeom
2. Put 3rd party geometry code into matgeom package (which will just
package what comes from matgeom developers)
3. mapping will have to depend on geometry, which in turns depends on

Now the BIG issue with this:
The reason I tried to convert matgeom to octave standard was to be
able to include the package in OF. This is currently a nightmare!
So by making an Octave package matgeom that can be easily synched with
upstream, I will have to abandon Octave and OF standards and matgeom
wont be hosted in OF anymore cause it will be not compliant.
This means installation of packages that depend on matgeom wont be
automatic, e.g.
pkg install -forge geometry
will always fail due to missing dependency matgeom.

What to do in this scenario?

One alternative I see is to fork only what our extensions actually
need from matgeom and put those in geometry in a OF complaint form
(definitely diverging from matgeom). Beware! This is not minor amount
of functions, and to do it in a reasonable time I will need help.

Is this scenario better?

AFAICS the underlying question is:
"Is it acceptable for an OF package to depend on an external package?",
Because this is gonna happen either way as far as OF-mapping goes: either mapping depends on an external geometry, or mapping depends on OF geometry that depends on external matgeom.

At the very moment the decision was made (AFAIR with fairly good reason) to have OF packages an external packages, I already figured there would be corner cases; simply because every sort of "yes/no" or "in/out" distinction inevitably brings those along.

My stance, from a practical POV, would be to just include matgeom as-is in a subdir (probably with some hierarchy inside) of an OF geometry package so that it can be somehow marked "external". As long as all functions are documented and have copyright + license info I suppose we're okay (that could be just some awk script or even sed). There are already some wrapper functions linking to the matgeom functions anyway. Perhaps doumentation may need a bit of thinking over, but there already is some, or even all docs.

TTBOMK there are existing examples: external gdalread.cc in mapping/src/, slicot in control, clipperlib in geometry/src/, .... all of which may or may not comply to formal OF standards.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]