 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymous org> wrote:
> On 12/3/19 12:07 PM, jr wrote:
> >
> ...
> >>
> >> Anyway, very likely more than a month before I'd have the time to look
> >> at this in any depth.
> >
> > also no problem (for me). out of interest, what advantages does your fork have
> > wrt media artefacts, media in general?
> >
> ...
> >
>
> :-) Simple question with a non-simple answer...
>
> I've never published a merged branch of all the branches I run as 'povr'
> - partly because what I run contains more branches / differences to
> master than those I've published to github. Also 'povr' is meant to be a
> temporal thing based on the current master branch into which continually
> re-based to master branches are merged.
>
> That said, my published solver branch addresses many artifacts media and
> otherwise - and extends the range over which containers work for media.
> This work though is limited to shapes using the common solvers.
sounds like a good starting point. artefacts seem to appear when I use
interpolation, so interested in the difference that code will make. what is the
build/install procedure? (sorry to use up yr time, mostly familiar with the
usual '.tar's, not "pulling" (+ merging?))
> ...
>
http://news.povray.org/povray.binaries.images/thread/%3C5a842989%241%40news.povray.org%3E/
> ...
thank you for this link. bookmarked. much to take in.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/4/19 12:10 PM, jr wrote:
...
>>
>> I've never published a merged branch of all the branches I run as 'povr'
>> - partly because what I run contains more branches / differences to
>> master than those I've published to github. Also 'povr' is meant to be a
>> temporal thing based on the current master branch into which continually
>> re-based to master branches are merged.
>>
>> That said, my published solver branch addresses many artifacts media and
>> otherwise - and extends the range over which containers work for media.
>> This work though is limited to shapes using the common solvers.
>
> sounds like a good starting point. artefacts seem to appear when I use
> interpolation, so interested in the difference that code will make. what is the
> build/install procedure? (sorry to use up yr time, mostly familiar with the
> usual '.tar's, not "pulling" (+ merging?))
>
...
>
Interpolation with respect to media... Not completely sure what you
mean, but, there are directions on my wiki page at:
http://wiki.povray.org/content/User:Wfpokorny
Though the branches available are out of date on it(1). You can get a
current list of published branches on github. A graph/network view be
seen by going to:
https://github.com/wfpokorny/povray/network
and you can also see a list using the branch switching list-pick button
on the page:
https://github.com/wfpokorny/povray
You have to be in a position to build your own *nix versions of POV-Ray
If you're not, well, what I have out there today isn't going to be
useful to you.
You need to have git installed and to have a local clone of povray to
follow the pick and chose branches to merge into your personal version
of POV-Ray method on the wiki. If you are compiling via download and
just want to try a single branch, you can switch to it, download the
branch to your machine & compile normally.
Bill P.
(1) - The inability to add new links to discussion and documentation
made the wiki much less useful - and I've more or less just been letting
my pages sit as is for long time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/4/19 12:10 PM, jr wrote:
> ...
> > sounds like a good starting point. artefacts seem to appear when I use
> > interpolation, so interested in the difference that code will make. what is the
> > build/install procedure? (sorry to use up yr time, mostly familiar with the
> > usual '.tar's, not "pulling" (+ merging?))
> ...
> Interpolation with respect to media... Not completely sure what you
> mean, but, there are directions on my wiki page at:
in a 'density {}' loaded from df3.
> http://wiki.povray.org/content/User:Wfpokorny
> Though the branches available are out of date on it(1). You can get a
> current list of published branches on github. A graph/network view be
> seen by going to:
> https://github.com/wfpokorny/povray/network
> and you can also see a list using the branch switching list-pick button
> on the page:
> https://github.com/wfpokorny/povray
>
> You have to be in a position to build your own *nix versions of POV-Ray
> If you're not, well, what I have out there today isn't going to be
> useful to you.
right, had a quick look at your wiki page. so generally, first git clone
POV-Ray master, then the checkout/pull sequence near bottom (with name of
branch)? I found an ebook/pdf (by S Chacon), am resigned to having to read it.
...in the coming days. :-)
> ...
> (1) - The inability to add new links to discussion and documentation
> made the wiki much less useful - and I've more or less just been letting
> my pages sit as is for long time.
I've been toying with the idea of trying to get a wiki page, for the df3-tools
mainly. but the site seems quite static, not really encouraging contribution (I
feel).
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/6/19 10:59 AM, jr wrote:
...
>> Interpolation with respect to media... Not completely sure what you
>> mean, but, there are directions on my wiki page at:
>
> in a 'density {}' loaded from df3.
>
Ah, OK. Depending on how you're using the df3 in media it might be worth
giving my wiki page:
http://wiki.povray.org/content/User:Wfpokorny/DensityFile
a read. There are issues with the df3 interpolation which can make using
it tricky.
> right, had a quick look at your wiki page. so generally, first git clone
> POV-Ray master, then the checkout/pull sequence near bottom (with name of
> branch)? I found an ebook/pdf (by S Chacon), am resigned to having to read it.
> ...in the coming days. :-)
>
Yeah, you got the idea. Intent was to set it up so folks building
POV-Ray themselves could roll their own derivatives of POV-Ray chosing
what branches they want to merge into the current master for their
version. Might be they have three branches of their own, might want to
use 2 of mine, 3 of SuperCoder12StrandedOnMarsEatingPotatoes etc.
>
>> ...
>> (1) - The inability to add new links to discussion and documentation
>> made the wiki much less useful - and I've more or less just been letting
>> my pages sit as is for long time.
>
> I've been toying with the idea of trying to get a wiki page, for the df3-tools
> mainly. but the site seems quite static, not really encouraging contribution (I
> feel).
>
...
Don't have time for real hobby coding this morning before being tied up
for some days. Why not some rambling thoughts about the wiki...
---
Over the last month or more, Maurice has been substantially improving the
http://wiki.povray.org/content/HowTo:Use_POV-Ray_with_Blender
page which can be found off of the
http://wiki.povray.org/content/HowTo:Contents
page. This evidence not everything is stale on the wiki. Folks do make
updates.
But, I agree the wiki is kinda stale. Writing wikis not too bad for
simple one page an image two sorts of things. For more, I find it
cumbersome.
In addition to trouble creating links to other pages:
To write more than one page, as with the density file pattern stuff, I
found the coding and previewing via the web cumbersome. I ended up
using a linux tool called Zim to first code, review, organize and refine
the pages locally(1). The wiki encoding though was slightly different
than that of POV-Ray's wiki implementation. It was a pain to transfer
everything to the POV-Ray wiki(2). I got some of this wrong due cut and
pasting, formatting differences, etc.
(1) - Zim a neat tool. Though it's spell checker broke for time while I
was using it due a Ubuntu release...
(2) - Now that everything on the POV-Ray wiki, major revisions can no
longer easily be done locally within Zim...
I found myself revising / changing images, but there is no way to delete
old ones yourself, so you end up being overly careful using images. With
some I replaced the image with much simpler "delete me" ones hoping some
admin would see this and do it. Suppose behavior might be due a wiki
being able to back up to old versions, but if I'm creating the first
release of some documentation I don't want all the old versions to exist
but just the 'released' one.
Once personal wiki's are up. They are sitting out there not very
visible. Is there even a page which lists user wikis? Maintained pages
sit on a wiki where lots of stuff has fallen out of date and needs
revision. People see that general staleness and shy away both from
reading the wiki entries - and from updating old ones.
Normal users cannot update the stuff they don't own. A few super users
can - spam concerns again I guess. This forces normal users into a "can
I get the attention of a super user;" then into a sort of type this,
then this, kinda of loop with them; on seeing some wrong or wanting some
change. This loop too is cumbersome. It gets to there being nobody being
paid to stay on top of the wiki and documentation always. Someone always
finding and refining issues as their job. We have similar issues with
the core documentation/build and release systems too as mentioned
elsewhere.
With user wikis there is always the problem that we might not completely
understand what we are trying to document ;-). What to do when well
intention-ed, but wrong pages get posted? Wikipedia has this problem
too. What they've done with subjects like Math is gather/(pay?) experts
as arbiters for what's written - much better end result, but still you
occasionally run across mistakes and biases in what's written.
We have a single physical web site. When it goes down or my local
network connection does, I'd like to have local copy of the wiki,
library and the newsgroup postings as I do for the documentation. Or at
least have snapshots of these available on the cloud - github or
wherever.
A few expert folk maintain their own web sites for what might go on a
wiki, but that an investment. Plus, knowing where all these web sites
are today means maintaining a list of links to them yourself.
Back to the Zim tool, its github wiki page at:
https://github.com/jaap-karssenberg/zim-wiki/wiki
is an interesting model for putting a wiki on github. The wiki link on
the Zim web site links to the github wiki above.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/6/19 10:59 AM, jr wrote:
> ...
> >> Interpolation with respect to media... Not completely sure what you
> >> mean, but, there are directions on my wiki page at:
> >
> > in a 'density {}' loaded from df3.
> >
> Ah, OK. Depending on how you're using the df3 in media it might be worth
> giving my wiki page: ,,,
> a read. There are issues with the df3 interpolation which can make using
> it tricky.
slightly confused by the interpolation options, they're not "regular" POV-Ray?
which of the 'playpen' branches deals with those?
> > right, had a quick look at your wiki page. so generally, first git clone
> > POV-Ray master, then the checkout/pull sequence near bottom (with name of
> > branch)? I found an ebook/pdf (by S Chacon), am resigned to having to read it.
> > ...in the coming days. :-)
>
> Yeah, you got the idea. Intent was to set it up so folks building
> POV-Ray themselves could roll their own derivatives of POV-Ray chosing
> what branches they want to merge into the current master for their
> version. Might be they have three branches of their own, might want to
> use 2 of mine, 3 of SuperCoder12StrandedOnMarsEatingPotatoes etc.
after some thought, the 'Density File Pattern Updates' + 'Non-portable 32 bit
DF3 write capability' + perhaps 'Both image_map and pigment_map support in
density block'. would that combination "play nice"?
> >> ...
> >> (1) - The inability to add new links to discussion and documentation
> >> made the wiki much less useful - and I've more or less just been letting
> >> my pages sit as is for long time.
> >
> > I've been toying with the idea of trying to get a wiki page, for the df3-tools
> > mainly. but the site seems quite static, not really encouraging contribution (I
> > feel).
> >
> ...
> (1) - Zim a neat tool. Though it's spell checker broke for time while I
> was using it due a Ubuntu release...
thanks. not an immediate need (for me), have O'Reilly's "MediaWiki", but have
some time ago switched to using the 'fossil' in-built wiki for most stuff.
> ...
> Once personal wiki's are up. They are sitting out there not very
> visible. Is there even a page which lists user wikis?
know what you mean. although they all have "sitemap"s, few provide table of
contents. (self-defeating, imo)
> ...
> With user wikis there is always the problem that we might not completely
> understand what we are trying to document ;-). What to do when well
> intention-ed, but wrong pages get posted?
isn't that what the "discussion" page is there for?
inadvertent errors would be corrected, I'm (fairly) sure.
> ...
> We have a single physical web site. When it goes down or my local
> network connection does, I'd like to have local copy of the wiki,
> library and the newsgroup postings as I do for the documentation. Or at
> least have snapshots of these available on the cloud - github or
> wherever.
> A few expert folk maintain their own web sites for what might go on a
> wiki, but that an investment. Plus, knowing where all these web sites
> are today means maintaining a list of links to them yourself.
it would be nice to have mirror or two. (personally, I think that if "the gods"
put the content on a DVD (or two) and offered those for sale, I'd buy. and
help maintain .. POV-Ray, I would. (and am quite certain that I'm not alone in
that))
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/9/19 5:03 PM, jr wrote:
...
Apparently I started a response months back and didn't finish it.
(Thunderbird was not showing anything sitting in my drafts folder.)
Up front. I'm changing direction. I'm working toward a personal,
substantially cut down, *nix only version of POV-Ray. With new git (or
perhaps mercurial) repositories once I get done with all the pruning.
Meaning, while the branches I've posted are today still pull-able
against the last commit to master more than a year ago, I no longer plan
to update/re-base those branches should POV-Ray development resume.
-----
Now, completing the response to your months old questions:
>
> slightly confused by the interpolation options, they're not "regular" POV-Ray?
Yes and no.
In my 'Density File Pattern Updates' branch interpolation 0 is the only
option which remains untouched(a). Interpolations 1 & 2 work the same
except the voxel half offset is fixed - voxels values are centered as
they always should have been (Christoph asked me to add options 11 & 12
IIRC which work with the half voxel offsets/overruns as before or like 1
& 2 today, so there was a path for folks to duplicate the incorrect
behavior for replication of old scenes).
(a) - Lying. There is a somewhat substantial performance improvement
achieved by avoiding duplicate work.
There are new interpolations 3,4,5 which use a kind of exponential
blobbing and aimed mostly at creating base isosurface functions/shapes
though, of course, they can be used as patterns too.
There are some new pattern value generation helper interpolations in 9 &
10 which look for the nearest non-zero, '0' interpolation which can then
be used for complex patterning on shapes. This relates to general
efforts. I've been attempting to come up with better ways to texture
which allowing a larger set of pattern and shape modifiers. Warp{} the
isosurface (or collection of placed objects) and use the same warp for
the shape's texturing. I've posted examples of this a few times.
Interpolations 9 & 10 are basically exploring the idea of painting
shapes with DF3s - using DF3 files as a texture mapping method.
Aside: Today interpolations 1 & 2 have seam and ringing artefacts,
respectively, limiting their usefulness as functions / shapes. The same
sort of problem we have today in v3.8 with the new blob potential
pattern use - because blob shapes themselves have continuity issues when
actually blobbing.
...
>
> after some thought, the 'Density File Pattern Updates' + 'Non-portable 32 bit
> DF3 write capability' + perhaps 'Both image_map and pigment_map support in
> density block'. would that combination "play nice"?
>
Yes, should be you can use all those at once. I've made an effort to
keep the branches independent even changing a couple slightly in the
interim so they don't collide(1,2).
(1) - Single branches are tested alone. For multiple pulls, I test this
only in the order of pulls I use to build my 'povr' version. So, there
is a chance when pulling multiple branches I missed some detail where
order matters.
(2) - I did a lot of work in the solver branch to standardize / cleanup
epsilons and other 'magic' values which were all over the place in use
and effectiveness. Thus far I've not used those fixes in other branches
- though it's gotten harder and harder not to do this. The wave modifier
/ pattern / function cleanup I've been working on need the better set
'epsilon-like' values too.
>> ...
>> Once personal wiki's are up. They are sitting out there not very
>> visible. Is there even a page which lists user wikis?
>
> know what you mean. although they all have "sitemap"s, few provide table of
> contents. (self-defeating, imo)
>
Yep, agree.
>
>> ...
>> With user wikis there is always the problem that we might not completely
>> understand what we are trying to document ;-). What to do when well
>> intention-ed, but wrong pages get posted?
>
> isn't that what the "discussion" page is there for?
>
> inadvertent errors would be corrected, I'm (fairly) sure.
>
Yes, ideally.
>
>> ...
>> We have a single physical web site. When it goes down or my local
>> network connection does, I'd like to have local copy of the wiki,
>> library and the newsgroup postings as I do for the documentation. Or at
>> least have snapshots of these available on the cloud - github or
>> wherever.
>> A few expert folk maintain their own web sites for what might go on a
>> wiki, but that an investment. Plus, knowing where all these web sites
>> are today means maintaining a list of links to them yourself.
>
> it would be nice to have mirror or two. (personally, I think that if "the gods"
> put the content on a DVD (or two) and offered those for sale, I'd buy. and
> while on money, if I could take out an annual subscription of 10-15 € or USD to
> help maintain .. POV-Ray, I would. (and am quite certain that I'm not alone in
> that))
>
Christoph had button up at one point (for uberpov only?), but it was to
some new-ish site and I'm leery of those. I'd subscribe too to support
POV-Ray - if the payment mechanism reputable.
Have you seen where github itself is pushing / supporting better ways to
financially support open source projects (GitHub sponsors)? For example:
https://www.youtube.com/watch?v=FYkBA9epUEk
and
https://www.youtube.com/watch?v=e_zhHQXTwVo
and
https://help.github.com/en/github/administering-a-repository/displaying-a-sponsor-button-in-your-repository
I've watched a few of the videos and they're good in pointing out that,
in other than single developer projects, support means more than just
gathering money. It means establishing and maintaining a governing group
deciding direction / how to spend. Otherwise you can end up with a pile
of money and no idea/mechanism for how to spend it...
I'd pay for a web-news group database searchable dump too (perhaps USB
over DVD... :-) ) - the news server representation is only correct for
the more current posts (last 10 years or so). Searches done via
thunderbird don't turn up - say pre 2007 stuff - though how far back it
works depends some on the group. If you know it's an old topic, the web
search is the only way to go - but a few times now I've struggled
finding what I want with this google based method.
Aside: Chris taught me individual groups can be searched via google with
arguments:
site:news.povray.org/povray.bugreports/ freezes
but that doesn't turn up anything, where say:
site:news.povray.org/povray.bugreports/ crash
does. Not dug much, but it seems like the google indexing is perhaps
done only once in a while - like it's lagging substantially (a year?).
Don't know. The by group method is useful, but I find myself not
counting on the google search completely either at this point.
Anyway... Having a paid support mechanism / data-products of some kind
or not, would be up to the core team / Chris I'd guess.
------------
FYI. I captured your February dictionary parsing bug test case for my
own use - thanks. No idea if/when I might get to looking at it, but it's
now one of my parser test cases.
My apologies for the SLOW response.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/9/19 5:03 PM, jr wrote:
> ...
> Apparently I started a response months back and didn't finish it.
> (Thunderbird was not showing anything sitting in my drafts folder.)
try handkerchief + knots. :-)
> Up front. I'm changing direction. I'm working toward a personal,
> substantially cut down, *nix only version of POV-Ray. With new git (or
> perhaps mercurial) repositories once I get done with all the pruning.
> Meaning, while the branches I've posted are today still pull-able
> against the last commit to master more than a year ago, I no longer plan
> to update/re-base those branches should POV-Ray development resume.
intriguing. does "substantially cut down" translate into subset of (current)
features?
> -----
> Now, completing the response to your months old questions:
>
> >
> > slightly confused by the interpolation options, they're not "regular" POV-Ray?
> Yes and no.
> ...
> Aside: Today interpolations 1 & 2 have seam and ringing artefacts,
> respectively, limiting their usefulness as functions / shapes. ...
the problem I'm seeing with media, artifacts (almost like "shadows") when using
interpolation(s).
> > after some thought, the 'Density File Pattern Updates' + 'Non-portable 32 bit
> > DF3 write capability' + perhaps 'Both image_map and pigment_map support in
> > density block'. would that combination "play nice"?
> >
> Yes, should be you can use all those at once. I've made an effort to
> keep the branches independent even changing a couple slightly in the
> interim so they don't collide(1,2).
good, thanks.
> ...
> >> We have a single physical web site. When it goes down ...
> > it would be nice to have mirror or two. (personally, I think that if "the gods"
> > put the content on a DVD (or two) and offered those for sale, I'd buy. and
> > while on money, if I could take out an annual subscription of 10-15 € or USD to
> > help maintain .. POV-Ray, I would. (and am quite certain that I'm not alone in
> > that))
> >
> Christoph had button up at one point (for uberpov only?), but it was to
> some new-ish site and I'm leery of those. I'd subscribe too to support
> POV-Ray - if the payment mechanism reputable.
:-) personally like using PayPal, but see below.
> Have you seen where github itself is pushing / supporting better ways to
> financially support open source projects (GitHub sponsors)? For example:
> ...
I like the apparent simplicity of a single button, but wasn't familiar with any
of the names except Patreon. but yes, contributing via the project's home page
does seem sensible.
> I'd pay for a web-news group database searchable dump too (perhaps USB
> over DVD... :-) ) ...
(just) showing my age. :-)
> Aside: Chris taught me individual groups can be searched via google with
> arguments:
yes, although I tend to just use 'site: povray.org'. there's a whole vocabulary
for narrowing searches (including '+' and '-' attached to individual
words/terms, though haven't a good reference to hand).
> ...
> Anyway... Having a paid support mechanism / data-products of some kind
> or not, would be up to the core team / Chris I'd guess.
given his (understandable) pride in reaching the 25 year milestone recently, one
would hope he'll read our remarks and (deign to) comment; not holding my
breath..
> FYI. I captured your February dictionary parsing bug test case for my
> own use - thanks. No idea if/when I might get to looking at it, but it's
> now one of my parser test cases.
>
> My apologies for the SLOW response.
no need. cheers.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/20/20 6:20 AM, jr wrote:
...
>
> intriguing. does "substantially cut down" translate into subset of (current)
> features?
>
Eventually I hope; got a list in my head.
The initial work has more to do with how things are organized and built.
Attempting gnu make instead of autotool's automake -> make, for example.
Lots of little things are wrong - or not quite right - in our *nix build
system. Starting too from a new base with many of my branches merged.
Initial git repository included large boost and other libraries for
windows builds. The size required is now much smaller due Christoph's
work to move to c++11 threads, but as a code repository that old library
data doesn't go away. On *nix we don't need these libraries in the
repository at all.
The documentation(1), includes, sample scenes and code are all in the
same repository and I think it would be better as 4 different ones.
Though, I'm focused today on the one with the code.
Dumping the other than linux code. Otherwise, pruning the code and
comments as much as I can. To do my own thing - with any chance of
wrapping my head around the whole - code needs to be a POV-Ray cut down.
I don't know windows coding and have no interest in learning. I don't
care about the windows editor interfaces, certain functionality, etc.
A second reason to work on a cut down is my son bought me a Raspberry Pi
4 (4GB) board for Christmas. There, even more so than on my main
machine, I want to develop and run things entirely on a ramdisk. This
limits the playpen as a whole to 2GB or so.
Bill P.
(1) - Recently someone submitted a github request asking for the
documentation to be pulled out as its own repository (and with a
documentation specific license IIRC). Seems a pretty common approach on
github(1a). I just want that, the editor templates etc out of the way.
(1a) - Documentation images/binaries are also often handled 'off to the
side' of git/mercurial distributed type code control systems and these
files are in our git repository.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
If you are ever looking for a polyvalent build system for the POVRay sources (as
much for Windows than Linux than other platforms), you should take a look at
"CMake" (www.cmake.org). Personnally , I use it for my projects and don't regret
it. All you have to do is writing a file:
CMakeLists.txt (with the cmake scripting language.)
Then the user who has downloaded (for example) the POVRay source code can choose
the compiler, the project type (that can be 'Codelite project'/'Visual studio
project'/'Unix Makefile'/'MinGW makefile' or many else).
Cmake is well known nowadays. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/20/20 2:35 PM, Warren wrote:
> If you are ever looking for a polyvalent build system for the POVRay sources (as
> much for Windows than Linux than other platforms), you should take a look at
> "CMake" (www.cmake.org). Personnally , I use it for my projects and don't regret
> it. All you have to do is writing a file:
> CMakeLists.txt (with the cmake scripting language.)
> Then the user who has downloaded (for example) the POVRay source code can choose
> the compiler, the project type (that can be 'Codelite project'/'Visual studio
> project'/'Unix Makefile'/'MinGW makefile' or many else).
>
> Cmake is well known nowadays. ;-)
>
Yes, I'm aware of cmake having looked at many build systems while
digging into a particular build issue back in 2017. I think it's
strengths come to good support for IDEs and common usage which increased
especially while the autotools package support was unstable and
fractured in the 2000s. It's weakness is it needs to be installed to be
used(1); that it created it's own scripting language(2) which you have
to learn; and that like autotools you can get into version issues(2).
At a high level I'm headed in the opposite direction to cmake and
'autotools' support everything model with my cut down *nix only version
of POV-Ray. I'm looking to support much less in the way of OSs and
architectures to make my hobby like simpler.
Bill P.
(1) Not how POV-Ray is being provided today, but the autotools approach
is the developer creates the configure script and only that configure
script is packaged for a users/administrators to run ahead of a
compile/install. Nothing extra needs to be installed on the system
beyond having a compliant c++ compiler which is kinda cool.
(2) One build system I liked over both cmake and autotools - partly due
me already knowing tcl - was a tool called autosetup. It requires tcl to
run, but the package includes a tiny implementation of tcl called jim
tcl which it will compile on the fly - given an ansi-c compiler on the
system - if need be. This build system becomes part of a project's code
so no versioning issues. It's basically a couple guys though - and aimed
too at just *nix and mostly c/c++. In theory at least - gnu autoconf /
gnu make there is surer, if not at any given time better - support given
it's a GNU tool needed for linux and gnu core tool compiles.
Aside (2a): Seeing autosetup I wondered if the cmake guys could have
saved themselves some implementation effort by starting with an
extension language like tcl, lua or maybe scheme/guile. GNU make itself
now supports guile written functions - and dll extensions 'experimentally.'
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
