yet another patch for solaris

[Tor Didriksen]

Hi

On Solaris /bin/sh is actually sh rather than bash.

BTW: What's the procedure for actually uploading patches, and get them
reviewed/accepted/rejected?

-- didrik

Index: scripts/gtest-config.in
===================================================================
--- scripts/gtest-config.in (revision 336)
+++ scripts/gtest-config.in (working copy)
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash

# These variables are automatically filled in by the configure script.
name="@PACKAGE_TARNAME@"

[Vlad Losev]

On Wed, Nov 4, 2009 at 5:32 AM, Tor Didriksen <torm...@gmail.com> wrote:

Hi

On Solaris /bin/sh is actually sh rather than bash.

BTW: What's the procedure for actually uploading patches, and get them
reviewed/accepted/rejected?

That is explained on the GoogleTestDevGuide wiki page. In short, you sign a CLA and upload the patches to Rietveld. If they are short as yours is you can post them right to the group.

-- didrik

Index: scripts/gtest-config.in
===================================================================
--- scripts/gtest-config.in     (revision 336)
+++ scripts/gtest-config.in     (working copy)
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash

Actually, we do strive to use sh rather than Bash, to get better compatibility. If you spot a bashism in one of our scripts, please send a patch to squash it.
 

 # These variables are automatically filled in by the configure script.
 name="@PACKAGE_TARNAME@"

Regards,
Vlad

[Tor Didriksen]

On Wed, Nov 4, 2009 at 7:46 PM, Vlad Losev <vlad...@gmail.com> wrote:
>
>
> On Wed, Nov 4, 2009 at 5:32 AM, Tor Didriksen <torm...@gmail.com> wrote:
>>
>> Hi
>>
>> On Solaris /bin/sh is actually sh rather than bash.
>>
>> BTW: What's the procedure for actually uploading patches, and get them
>> reviewed/accepted/rejected?
>>
> That is explained on the GoogleTestDevGuide wiki page. In short, you sign a
> CLA and upload the patches to Rietveld. If they are short as yours is you
> can post them right to the group.
>
>> -- didrik
>>
>> Index: scripts/gtest-config.in
>> ===================================================================
>> --- scripts/gtest-config.in     (revision 336)
>> +++ scripts/gtest-config.in     (working copy)
>> @@ -1,4 +1,4 @@
>> -#!/bin/sh
>> +#!/bin/bash
>>
> Actually, we do strive to use sh rather than Bash, to get better
> compatibility. If you spot a bashism in one of our scripts, please send a
> patch to squash it.
>

gtest-svn/scripts/gtest-config: syntax error at line 123: `(' unexpected

test $(($major_version)) -lt $(($min_major_version)) && exit 1

this line
if test "${this_bindir}" = "${this_bindir%${bindir}}"; then
gives "bad substitution"

I don't know how to rewrite the last one to sh

-- didrik

[Vlad Losev]

Hrm, this doesn't seem to be a bashism. http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html describes this kind of variable expansion as supported by sh.

Chandler - do you know if this is indeed a bashism and if what can we do about it?

 
Thanks,
Vlad

[Tor Didriksen]

Thanks, it seems that /bin/sh in solaris is really old (backward
compatibility I presume).
Solaris has /usr/xpg4/bin/sh, and of course /bin/bash which both handle the
${parameter%word} substitution.

-- didrik

[Tor Didriksen]

Hi again.

re: /bin/sh and posix

You should actually not assume that /bin/sh is posix compliant.
There's a posix-shell.m4 out there that you can possibly use if you
need to use posix features.

-- didrik

[Vlad Losev]

Hi Tor,

On Wed, Dec 2, 2009 at 1:56 PM, Tor Didriksen <torm...@gmail.com> wrote:

Hi again.

re: /bin/sh and posix

You should actually not assume that /bin/sh is posix compliant.
There's a posix-shell.m4 out there that you can possibly use if you
need to use posix features.

Considering /sin/sh POSIX compliant is a relatively safe assumption, IMHO. ;-)

Anyway, thanks for the tip.

Chandler - what do you think about viability of using this script in gtest?

Is there a good way to replace the hasbanged /bin/sh in gtest-config.in with the result of this script?

Thanks,

Vlad

[Tor Didriksen]

On Thu, Dec 3, 2009 at 1:12 AM, Vlad Losev <vlad...@gmail.com> wrote:
> Hi Tor,
>
> On Wed, Dec 2, 2009 at 1:56 PM, Tor Didriksen <torm...@gmail.com> wrote:
>>
>> Hi again.
>>
>> re: /bin/sh and posix
>>
>> You should actually not assume that /bin/sh is posix compliant.
>> There's a posix-shell.m4 out there that you can possibly use if you
>> need to use posix features.
>>
> Considering /sin/sh POSIX compliant is a relatively safe assumption, IMHO.
> ;-)

Please se the Autoconf manual, Chapter 11: Portable Shell Programming

>> While most (at least most System V’s) do have
>> a Bourne shell that accepts shell functions most vendor /bin/sh programs are
>> not the Posix shell.
>> So while most modern systems do have a shell somewhere that meets the Posix
>> standard, the challenge is to find it.

So maybe it is safer to use /bin/bash, rather than hoping that /bin/sh
will be able to parse gtest-config

-- didrik

[Chandler Carruth]

On Wed, Dec 2, 2009 at 4:12 PM, Vlad Losev <vlad...@gmail.com> wrote:
> Hi Tor,
>
> On Wed, Dec 2, 2009 at 1:56 PM, Tor Didriksen <torm...@gmail.com> wrote:
>>
>> Hi again.
>>
>> re: /bin/sh and posix
>>
>> You should actually not assume that /bin/sh is posix compliant.
>> There's a posix-shell.m4 out there that you can possibly use if you
>> need to use posix features.
>>
> Considering /sin/sh POSIX compliant is a relatively safe assumption, IMHO.
> ;-)
> Anyway, thanks for the tip.
> Chandler - what do you think about viability of using this script in gtest?

We could.

> Is there a good way to replace the hasbanged /bin/sh in gtest-config.in with
> the result of this script?

Yes, its trivial.

However, I am unenthusiastic about supporting such systems, and adding
complexity to an overly complex build for their benefit. Do these
systems need gtest-config at all? Can they not use the one-makefile
approach? What is the motivation for this?

Generally speaking, I'd like to shoot the autotools build in the head.
I want to see it become simpler and less feature rich; not the other
way around. I'd really like to see focus going into more reasonable
build systems such as CMake.

I guess in the end I'm willing to review and commit patches submitted
to use posix-shell.m4, but I probably won't have time or motivation to
do it myself.

[Chandler Carruth]

On Wed, Dec 2, 2009 at 11:30 PM, Tor Didriksen <torm...@gmail.com> wrote:
> On Thu, Dec 3, 2009 at 1:12 AM, Vlad Losev <vlad...@gmail.com> wrote:
>> Hi Tor,
>>
>> On Wed, Dec 2, 2009 at 1:56 PM, Tor Didriksen <torm...@gmail.com> wrote:
>>>
>>> Hi again.
>>>
>>> re: /bin/sh and posix
>>>
>>> You should actually not assume that /bin/sh is posix compliant.
>>> There's a posix-shell.m4 out there that you can possibly use if you
>>> need to use posix features.
>>>
>> Considering /sin/sh POSIX compliant is a relatively safe assumption, IMHO.
>> ;-)
>
> Please se the Autoconf manual, Chapter 11: Portable Shell Programming
>
>>>                               While most (at least most System V’s) do have
>>> a Bourne shell that accepts shell functions most vendor /bin/sh programs are
>>> not the Posix shell.
>>> So while most modern systems do have a shell somewhere that meets the Posix
>>> standard, the challenge is to find it.
>
> So maybe it is safer to use /bin/bash, rather than hoping that /bin/sh
> will be able to parse gtest-config

This merely gets us into two messes: ensuring the system has bash, and
handling the incompatibilities between versions. Personally, I like
standards, so I like POSIX shell here. After all, this is a
convenience script, not a necessary or integral part of gtest. It's
entirely reasonable to use gtest without ever running 'gtest-config'.

[Hady Zalek]

Hi everyone,

I second the move to CMake. It works like a charm and is much (much much) more maintainable.

My two cents,
Hady

2009/12/3 Chandler Carruth <chan...@gmail.com>

[Zhanyong Wan (λx.x x)]

On Thu, Dec 3, 2009 at 1:16 AM, Chandler Carruth <chan...@gmail.com> wrote:
> On Wed, Dec 2, 2009 at 4:12 PM, Vlad Losev <vlad...@gmail.com> wrote:
>> Hi Tor,
>>
>> On Wed, Dec 2, 2009 at 1:56 PM, Tor Didriksen <torm...@gmail.com> wrote:
>>>
>>> Hi again.
>>>
>>> re: /bin/sh and posix
>>>
>>> You should actually not assume that /bin/sh is posix compliant.
>>> There's a posix-shell.m4 out there that you can possibly use if you
>>> need to use posix features.
>>>
>> Considering /sin/sh POSIX compliant is a relatively safe assumption, IMHO.
>> ;-)
>> Anyway, thanks for the tip.
>> Chandler - what do you think about viability of using this script in gtest?
>
> We could.
>
>> Is there a good way to replace the hasbanged /bin/sh in gtest-config.in with
>> the result of this script?
>
> Yes, its trivial.
>
> However, I am unenthusiastic about supporting such systems, and adding
> complexity to an overly complex build for their benefit. Do these
> systems need gtest-config at all? Can they not use the one-makefile
> approach? What is the motivation for this?
>
> Generally speaking, I'd like to shoot the autotools build in the head.

I can hardly wait. :-) How many users actually prefer the autotools
build? And how many use it just because it comes with gtest?
(Serious questions)

Let's start with killing gtest's own tests. We already have a scons
script to build them.

--
Zhanyong

[Vlad Losev]

2009/12/3 Zhanyong Wan (λx.x x) <w...@google.com>

Well, I would like to take a couple of things into consideration when considering this. Of all the users' bug reports on *NIX systems, in every single case autotools were used to build and run tests. If we remove tests from autotools we lose a valuable source of bug reports. Plus, problems in building tests for gtest are likely to pop up in users' own tests. It is more convenient to receive a report about our test breaking on user's system than about user test breaking. In the latter case we first have to determine where the problem lies.

- Vlad

[Zhanyong Wan (λx.x x)]

2009/12/3 Vlad Losev <vlad...@gmail.com>:

Often the bug is in the autotools script itself, which is a total
waste of time for us and for the user.

> If we remove tests
> from autotools we lose a valuable source of bug reports.

I'm happy to kill an entire category of bugs. :-)

After removing the test targets from autotools, we'll tell the users
autotools is not the preferred build system any more. They should use
scons (or CMake when it's available) to build and run the tests.

> Plus, problems in
> building tests for gtest are likely to pop up in users' own tests. It is
> more convenient to receive a report about our test breaking on user's system
> than about user test breaking. In the latter case we first have to determine
> where the problem lies.

We'll ask the user to reduce the bug report to a minimal report first.

--
Zhanyong

[Lenny Primak]

I went through an exercise recently of evaluating build tools.
the qualities i was looking for are:
- cross platform
- easy to use
- understandable
- small/fast for large code bases

I evaluated:
- make (old/too manual/tabs in files)
- autocont/automake (too complicated)
- ant/cpptasks (xml buildfiles)
- scons (too compliacted/have to know python?)
- boost.build v2 (too complicated, too many conf files to make it
work)
- cmake (too complicated/half baked)
- jam (raw - too raw)
- opus make (old, not maintained, commercial)

Winner: ant. Simple, works out of the box, no config files, works
in all cases, configurable in cases it doesn't.

On Dec 3, 2:37 pm, Vlad Losev <vladlo...@gmail.com> wrote:
> 2009/12/3 Zhanyong Wan (λx.x x) <w...@google.com>
>
>
>

> > On Thu, Dec 3, 2009 at 1:16 AM, Chandler Carruth <chandl...@gmail.com>
> > wrote:

> > > On Wed, Dec 2, 2009 at 4:12 PM, Vlad Losev <vladlo...@gmail.com> wrote:
> > >> Hi Tor,
>

> > >> On Wed, Dec 2, 2009 at 1:56 PM, Tor Didriksen <torma...@gmail.com>

> > >>> On Fri, Nov 6, 2009 at 8:11 AM, Tor Didriksen <torma...@gmail.com>
> > wrote:
> > >>> > On Fri, Nov 6, 2009 at 4:38 AM, Vlad Losev <vladlo...@gmail.com>
> > wrote:
> > >>> >> On Thu, Nov 5, 2009 at 12:18 AM, Tor Didriksen <torma...@gmail.com>
> > >>> >> wrote:
>
> > >>> >>> On Wed, Nov 4, 2009 at 7:46 PM, Vlad Losev <vladlo...@gmail.com>

> > >>> >>> wrote:
>
> > >>> >>> > On Wed, Nov 4, 2009 at 5:32 AM, Tor Didriksen <

> > torma...@gmail.com>

[Hady Zalek]

Hi Lenny,

I recently went through the same exercise and IMO Ant is too primitive. No incremental builds, you need java, etc...I'm surprised though that you think that CMake is half baked. KDE is using it and Boost is migrating to it.

I also found this interesting discussion:
http://stackoverflow.com/questions/1034138/antcpptasks-vs-scons-vs-make

Cheers,
Hady

2009/12/3 Lenny Primak <lenny...@gmail.com>

[Lenny Primak]

For me, Simple/Works out-of-the-box is very much of an advantage.
Ant/cpptasks's 'primitiveness' is what i like most about it.
You can literally get a large C++ project going with 5 lines in ant/
cpptasks
It works great and powerful. And dependencies/incremental builds work
perfectly.
And, Java is awesome. What's not to like?
CMake tries to do too many things IMHO and none of them particularly
well.

On Dec 4, 5:01 am, Hady Zalek <hady.za...@gmail.com> wrote:
> Hi Lenny,
>
> I recently went through the same exercise and IMO Ant is too primitive. No
> incremental builds, you need java, etc...I'm surprised though that you think
> that CMake is half baked. KDE is using it and Boost is migrating to it.
>
> I also found this interesting discussion:http://stackoverflow.com/questions/1034138/antcpptasks-vs-scons-vs-make
>
> Cheers,
> Hady
>

> 2009/12/3 Lenny Primak <lennypri...@gmail.com>

[Hady Zalek]

Well, ideally I would have chosen a maven-based approach. Unfortunately, they've got even poorer support for C++ projects. Anyways I just wanted to give you my opinion since we're in the process of replacing our ant build system which is getting too unwieldy.

Hady

2009/12/4 Lenny Primak <lenny...@gmail.com>