Re: [Geeqie-devel] Build for Geeqie

[Roger]

>
>Russel> I get the message. I'll go away.
>
>Christ, stop the passive aggresive stuff will you?  And get a thicker
>skin when people trash you suggestion.  If you feel so strongly about
>it, and if moving to CMake or some other tool will help you contribute
>in a major way to geeqie, then go ahead.
>
>Start a branch, start your work and put it out over the wall for
>others to see!  Please please please do not let some people not being
>excited for your idea mean they don't want YOU contributing.  They're
>down on the idea, not on you and your desire to contribute!
>
>John

I do not think anybody was even beginnning to trash his idea.  He just assumed 
we were.  (And you're probably correct, passive aggressive.  Albeit, maybe a 
wee bit obvious? ;-)

I could see where somebody might suggest integrating CMake to make a Windows 
port; but even then, we still have MinGW for AutoTools support within Windows.

-- 
Roger
http://rogerx.freeshell.org/

--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Build for Geeqie

[John Stoffel]

> "Russel" == Russel Winder  writes:

Russel> On Wed, 2016-11-16 at 07:43 -0500, Greg Troxel wrote:
Russel> […]

>> I have never heard of Meson before.  Certainly I may not be paying
>> enough attention, but it's hard to believe it is mainstream yet.

Russel> GStreamer for one is looking to replace Autotools with Meson.

>> While CMake is now reasonably common, the idea that some kind of
>> packaging system will only build packages that use Cmake is very odd.
>> Certainly large amounts of software does not use CMake, and it is not
>> reasonable to call something broken because it doesn't.
>> 
>> Before adopting a new build system, I'd like to see written
>> requirements
>> for the build system, specifically including portability and cross
>> building, and to see an analysis of how there will be no regressions.

Russel> This is a clear management tool to say "we are not going to do this".
Russel> Unlike the comment "Show us it working and we'll think about it" which
Russel> is positive, "write a proposal document" is, to a software project,
Russel> management speak that means "we will put up barriers to avoid any
Russel> change".

Russel> I get the message. I'll go away.

Christ, stop the passive aggresive stuff will you?  And get a thicker
skin when people trash you suggestion.  If you feel so strongly about
it, and if moving to CMake or some other tool will help you contribute
in a major way to geeqie, then go ahead.

Start a branch, start your work and put it out over the wall for
others to see!  Please please please do not let some people not being
excited for your idea mean they don't want YOU contributing.  They're
down on the idea, not on you and your desire to contribute!

John

--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Build for Geeqie

[Ian Zimmerman]

On 2016-11-19 08:55, Greg Troxel wrote:

> In the particular case I'm referring, the shiny things that replaced
> autotools was scons, and it's still causing problems, even years later.

Can you share some more details?  What build/host/target triple?  C, C++
or some other language?  Executable or shared library?

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Build for Geeqie

[Roger]

> On Sat, Nov 19, 2016 at 08:44:13AM +, Russel Winder wrote:
>On Wed, 2016-11-16 at 14:58 -0500, Roger wrote:
>> I have used AutoTools for my or others' projects as well in the past,
>> and find??
>> AutoTools quite stable, albeit sometimes cryptic to configure at
>> times.
>> 
>> I've tried educating myself with CMake, but found only low-level
>> documentation??
>> packaged with or available via CMake's website.All CMake's other
>> third party??
>> documentation costs, or are supposedly inadequate.Unfortunately or??
>> fortunately, CMake is still unusable at my end of the user
>> spectrum.As to??
>> Python being popular due to multi-platform use (and slow when
>> compared to??
>> C/C++/Bash Scripting); CMake is similar, providing cross-platform
>> use.
>
>The same is also true of Autotools, no nice documentation and way too
>low level, So CMake is at least a step up.

Autotools does offer a lot of documentation, however it is quite lengthy and 
seems to require additional lifetimes for reading and studying.  (e.g.  
Autotools A Practioner's Guide to GNU Autoconf, Automake, and Libtool By John 
Calcote, 2010; and the GNU Autoconf Manual offered in many formats such as 
HTML, ASCII Text, PDF, PostScript, ...)

>I do not see the logical connection between Python being slow compared
>to C++ and CMake.

Try programming using limited resources.  You'll quickly find C/C++ and likely 
most scripting preceeding Python to be much less resource intensive.  (Except 
for likely BASIC.)  No worries, many do not even obviously see this slowing 
effect, due to always having the fastest computers at their finger tips.  ;-)

...

>OK so you do not like Python. I'm afraid that is your problem.


>But I get the message: total lack of interest in anything other than
>Autotools.
>
>I am now sorry I even mentioned the idea of upgrading to a more modern
>approach to build.

... still quite busy learning Autotools here. ;-)

I personally would rather struggle a bit; versus forgetting all of my past 
lessons learned and getting spoiled and always relying on faster, more power 
consuming computers.  But then again, I do not get much time for coding 
nowadays except for Winters; although I am one of those always building (& 
sometimes) packing the software for distributions.

Sincerely,

Roger

--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Build for Geeqie

[Greg Troxel]

Russel Winder  writes:

>> Before adopting a new build system, I'd like to see written
>> requirements
>> for the build system, specifically including portability and cross
>> building, and to see an analysis of how there will be no regressions.
>
> This is a clear management tool to say "we are not going to do this".
> Unlike the comment "Show us it working and we'll think about it" which
> is positive, "write a proposal document" is, to a software project,
> management speak that means "we will put up barriers to avoid any
> change".

Not at all.  It's a reaction to seeing previous projects broken by
people who want to change to shiny new tool of the month, resulting in
losing the ability to cross build.  What I asked for is a page, maybe 2,
so that shiny-new-tool proponents will realize that there is more to a
build system than working for their use case.

In the particular case I'm referring, the shiny things that replaced
autotools was scons, and it's still causing problems, even years later.



signature.asc
Description: PGP signature
--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Build for Geeqie

[Russel Winder]

On Wed, 2016-11-16 at 07:43 -0500, Greg Troxel wrote:
[…]

> I have never heard of Meson before.  Certainly I may not be paying
> enough attention, but it's hard to believe it is mainstream yet.

GStreamer for one is looking to replace Autotools with Meson.

> While CMake is now reasonably common, the idea that some kind of
> packaging system will only build packages that use Cmake is very odd.
> Certainly large amounts of software does not use CMake, and it is not
> reasonable to call something broken because it doesn't.
> 
> Before adopting a new build system, I'd like to see written
> requirements
> for the build system, specifically including portability and cross
> building, and to see an analysis of how there will be no regressions.

This is a clear management tool to say "we are not going to do this".
Unlike the comment "Show us it working and we'll think about it" which
is positive, "write a proposal document" is, to a software project,
management speak that means "we will put up barriers to avoid any
change".

I get the message. I'll go away.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part
--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Build for Geeqie

[Russel Winder]

On Wed, 2016-11-16 at 12:39 -0800, Ian Zimmerman wrote:
> 
[…]
> I've never heard of mezon; if looking for a buildtool in python, why
> not
> scons?  I've used scons and I liked it the best of any build tools.

I have actually been known to work on SCons from time to time over the
last decade, and whilst it is still very good for straightforward C,
C++, Fortran, D and LaTeX builds, it is beginning to lag behind in
addressing some aspects of build, particularly configuration.

CMake and SCons(, and Waf) clearly led to Meson which is a Ninja
configuration system in the way CMake is a Make configuration system. 

> But in the context of geeqie, I'd say don't fix it as long as it's
> not
> broken.  If it breaks, we can return to this discussion.

An approach I find disappointing in a FOSS project, but it seems the
view of all those who ventured a view. Which is fine, it is the project
that belongs to those who work on it. I just think that this "don't fix
the unbroken" is a route to technical debt.

Anyway given the gently hostile reaction to my email, I shall now just
go away.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part
--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Build for Geeqie

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Russel,

Am Mi den 16. Nov 2016 um 11:40 schrieb Russel Winder:
> Geeqie currently has an Autotools build. A lot of the GTK world seems
> to be switching to Meson, or at least trying it out. JetBrains CLion
> only accepts CMake builds for projects (at least currently). Is the
> Geeqie team committed to using Autotools, or if an alternate build were
> available might it be accepted?

Well, let me tell it that way, the build tool is not set in stone.
But...

I see no need currently to even think about a new build tool.
Autoconf/automake serves what it is used for and it does it good. It
would take many work to change to other one.

- From the fact that the man power is very limited, this is a big NO.

On the other hand, I never heard of meson. Nor do I know (without
duckduckgoing) what "JetBrais CLion" is. IF there would be a need for
other build tool, I would more vote for something widely used (ok, cmake
is not that seldom). In the end, the chances would be pretty high that I
would end with automake/autoconf again when sorting the pro and cons.

So, for a new project, that would be something to think about. For a
existing project, there has to be a pretty good reason to switch the
build environment to something other with new bugs and new
inadequateness.

Am Do den 17. Nov 2016 um  1:57 schrieb Greg Troxel:
> Ian Zimmerman  writes:
> > But in the context of geeqie, I'd say don't fix it as long as it's not
> > broken.  If it breaks, we can return to this discussion.
> 
> That's a very good point.   geeqie seems to need more people to hack on
> the code, and the build system really isn't a problem at all.

No more to say. That is the most valid point here.

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlgtU/cACgkQpnwKsYAZ
9qyyEQwAu1GWpf4lyPEHpgm83NshESygMdRb21WLk2Ua8j0xYjmZAjwygM/1dh7T
HF/NV2dsXqClYgZHnAE/CStnukcOouPPYIR4WchJMKzlxCjKG2ZgDe+cwg6POE4j
nQN2jk4XAsqW5ijAbBfzgbddW3nQBoQKdvsgDm+/D3aOLvezeOrimanYF1IAe0Xj
nD9Jkd6jaEXsO7r9KNEpbhzQ9PA18TpabEb10NG2ZNRSYNexVRqsuJPiKJhmJU6D
igsbs9pYdQaQcD0j4GAtFIelsfRostRgMeYp1uY4MwFB2hH5RUhw3cafYl5h4m/H
1H30I31b/Z9RlJfdtiacvmp3ES0N4cu46855XRFd6UaRyZWgxJ2vcMZe14yzNw6d
ti2VsLKFcAPiuNeKr4U/Xcq5zxpddsHPtEtPFeDuqQm3/KfoNQep57wbtH139HXR
rC2dQLdscimrVtxKc8OpKaKtK8NvJG36y37ckiOwogbFHPk3evxGj3CHPAhOjfsx
emU5GFv9
=/578
-END PGP SIGNATURE-

--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Build for Geeqie

[Greg Troxel]

Ian Zimmerman  writes:

> But in the context of geeqie, I'd say don't fix it as long as it's not
> broken.  If it breaks, we can return to this discussion.

That's a very good point.   geeqie seems to need more people to hack on
the code, and the build system really isn't a problem at all.


signature.asc
Description: PGP signature
--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Build for Geeqie

[Ian Zimmerman]

On 2016-11-16 14:58, Roger wrote:

> I have used AutoTools for my or others' projects as well in the past,
> and find AutoTools quite stable, albeit sometimes cryptic to configure
> at times.

It's time for me to chime in even though I fear this is heading straight
for the bike shed ;-)

I have found autotools useful for handling situations that go beyond the
normal self hosted build, especially when cross compiling for embedded
systems.  But, I must say they're the opposite of "stable" as far as I'm
concerned.  Upgrade one piece and the whole thing breaks down horribly.
And constant churn means one must upgrade.  Gettext and the related
tools seem to be the worst.

I've never heard of mezon; if looking for a buildtool in python, why not
scons?  I've used scons and I liked it the best of any build tools.

But in the context of geeqie, I'd say don't fix it as long as it's not
broken.  If it breaks, we can return to this discussion.

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Build for Geeqie

[Roger]

Using "fgrep /usr/portage/* -r -e meson" on my Gentoo system, only results in 
media-plugins/gst-transcoder and media-video/pitivi packages using or 
optionally using the meson build system.

I think the Meson Wikipedia might be indicating GNOME, GTK+, GLib and GStreamer 
might be optionally providing meson support within each package's source code 
along side AutoTools or CMake.  So far, everything here on Gentoo seems to be 
either AutoTools and CMake, or other build system I cannot recall.

-- 
Roger
http://rogerx.freeshell.org/

--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Build for Geeqie

[Roger]

I have used AutoTools for my or others' projects as well in the past, and find 
AutoTools quite stable, albeit sometimes cryptic to configure at times.

I've tried educating myself with CMake, but found only low-level documentation 
packaged with or available via CMake's website.  All CMake's other third party 
documentation costs, or are supposedly inadequate.  Unfortunately or 
fortunately, CMake is still unusable at my end of the user spectrum.  As to 
Python being popular due to multi-platform use (and slow when compared to 
C/C++/Bash Scripting); CMake is similar, providing cross-platform use.

CMake is basically a wrapper around Make, so I do not expect to see the same 
inadequacies I see with Python, except for maybe adhering to standards.  Python 
constantly has been known to break standards in the past.  I do not know what 
standards CMake follows, nor if they've broken any with version releases.

When I code, I tend to go with what tools others' are commonly using, which 
tends to be tools that are most stable and lowest consuming in resources.

If some source code breaks within AutoTools, I can fix it.  CMake, I just 
forget about it here. Meson, never heard of it either.

Ah, Meson Wikipedia; "Being written in Python Meson runs natively on Linux 
kernel-based operating systems, on macOS, on Microsoft Windows and on other 
operating systems."  Maybe they've finally found something Python is useful at? 
 
Or maybe now my builds here are just going to get extremely more slower than 
using AutoTools?  (eg. Slower meaning more CPU usage, and more waste of 
electricity.)

-- 
Roger
http://rogerx.freeshell.org/

--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Build for Geeqie

[Greg Troxel]

Russel Winder  writes:

> Geeqie currently has an Autotools build. A lot of the GTK world seems
> to be switching to Meson, or at least trying it out. JetBrains CLion
> only accepts CMake builds for projects (at least currently). Is the
> Geeqie team committed to using Autotools, or if an alternate build were
> available might it be accepted?

(speaking for myself of course)

I have found autotools to be quite stable and sane over the years, if a
bit hard to set up for the project.  The newer tools seem to claim to be
better and then people struggle to get all the functionality of
autotools (such as cross building).  So I am very skeptical of changing
to a flavor-of-the-month build tool.

I have never heard of Meson before.  Certainly I may not be paying
enough attention, but it's hard to believe it is mainstream yet.

While CMake is now reasonably common, the idea that some kind of
packaging system will only build packages that use Cmake is very odd.
Certainly large amounts of software does not use CMake, and it is not
reasonable to call something broken because it doesn't.

Before adopting a new build system, I'd like to see written requirements
for the build system, specifically including portability and cross
building, and to see an analysis of how there will be no regressions.


signature.asc
Description: PGP signature
--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel