tools/ccdv

Someone has reported (on the main "linux-ha" list)
a problem building on
Solaris.  One of the aspects was "tools/ccdv".  So
I started looking...

In "tools/Makefile.am" the program
"ccdv" seems to get special treatment
(which always makes me suspicious!), as if it's trying to
bypass
'automake'.  But there is no explanation about why it needs
this special
treatment at all (except for a non-very-meaningful comment
in the middle
of the definition of a different program).

So while I'm visiting this, is there any reason not to
simplify this right
down to the usual 'automake' behaviour?

That obscure comment said "...auto-built but not
auto-cleaned".  Does
anyone know why is it necessary to avoid this being
auto-cleaned?  Etc.
Can I go ahead and normalise (and so simplify) this to the
usual
'automake' practice?



-- 

:  David Lee                                I.T. Service    
     :
:  Senior Systems Programmer                Computer Centre 
     :
:  UNIX Team Leader                         Durham
University     :
:                                           South Road      
     :
:  http://www.dur.ac.uk/t.
d.lee/            Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.            
     :
_______________________________________________________
Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Hi,

On Fri, Feb 29, 2008 at 11:19:50AM +0000, David Lee wrote:
> 
> Someone has reported (on the main "linux-ha"
list) a problem building on
> Solaris.  One of the aspects was
"tools/ccdv".  So I started looking...
> 
> In "tools/Makefile.am" the program
"ccdv" seems to get special treatment
> (which always makes me suspicious!), as if it's trying
to bypass
> 'automake'.  But there is no explanation about why it
needs this special
> treatment at all (except for a non-very-meaningful
comment in the middle
> of the definition of a different program).
> 
> So while I'm visiting this, is there any reason not to
simplify this right
> down to the usual 'automake' behaviour?
> 
> That obscure comment said "...auto-built but not
auto-cleaned".  Does
> anyone know why is it necessary to avoid this being
auto-cleaned?  Etc.
> Can I go ahead and normalise (and so simplify) this to
the usual
> 'automake' practice?

No objections here   But I
have no idea why did it get such a
special treatment.

Thanks,

Dejan

> 
> 
> -- 
> 
> :  David Lee                                I.T.
Service          :
> :  Senior Systems Programmer                Computer
Centre       :
> :  UNIX Team Leader                         Durham
University     :
> :                                           South Road 
          :
> :  http://www.dur.ac.uk/t.
d.lee/            Durham DH1 3LE        :
> :  Phone: +44 191 334 2752                  U.K.       
          :
>
_______________________________________________________
> Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

On 2008-02-29T11:19:50, David Lee <t.d.leedurham.ac.uk> wrote:

> So while I'm visiting this, is there any reason not to
simplify this right
> down to the usual 'automake' behaviour?
> 
> That obscure comment said "...auto-built but not
auto-cleaned".  Does
> anyone know why is it necessary to avoid this being
auto-cleaned?  Etc.
> Can I go ahead and normalise (and so simplify) this to
the usual
> 'automake' practice?

Andrew would know. He's currently on vacation. Be careful
with removing
it; I bet he has had a good reason. 

But if you can pretty it up and --enable-pretty still works,
sure.


Regards,
    Lars

-- 
Team lead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG
Nürnberg)
"Experience is the name everyone gives to their
mistakes." -- Oscar Wilde

_______________________________________________________
Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

On Fri, 29 Feb 2008, Lars Marowsky-Bree wrote:

> On 2008-02-29T11:19:50, David Lee <t.d.leedurham.ac.uk> wrote:
>
> > So while I'm visiting this, is there any reason
not to simplify this right
> > down to the usual 'automake' behaviour?
> >
> > That obscure comment said "...auto-built but
not auto-cleaned".  Does
> > anyone know why is it necessary to avoid this
being auto-cleaned?  Etc.
> > Can I go ahead and normalise (and so simplify)
this to the usual
> > 'automake' practice?
>
> Andrew would know. He's currently on vacation. Be
careful with removing
> it; I bet he has had a good reason. 

Thanks.  A local build had broken on the explicit 'gcc'; the
quick fix is
simply to make it $(CC), so I have done just that.

But it would be useful to have a comment in the source
saying why 'ccdv'
needs non-standard configure/make treatment.

Andrew: If you read this on your return, could you add a
brief comment?


> But if you can pretty it up and --enable-pretty still
works, sure.

No, I don't particularly want to get sidetracked into its
insides.  I was
simply wondering why, from the configure/make perspective,
it seems to be
a "special case".

Best wishes.

-- 

:  David Lee                                I.T. Service    
     :
:  Senior Systems Programmer                Computer Centre 
     :
:  UNIX Team Leader                         Durham
University     :
:                                           South Road      
     :
:  http://www.dur.ac.uk/t.
d.lee/            Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.            
     :
_______________________________________________________
Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

On 2008-02-29T15:39:07, David Lee <t.d.leedurham.ac.uk> wrote:

> > But if you can pretty it up and --enable-pretty
still works, sure.
> No, I don't particularly want to get sidetracked into
its insides.  I was
> simply wondering why, from the configure/make
perspective, it seems to be
> a "special case".

I _think_ this was related to the fact that it overrides the
CC
variable; we need to have ccdv ready before we can compile
anything, but
we obviously can't compile ccdv with ccdv already in the CC
setting.


Regards,
    Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG
Nürnberg)
"Experience is the name everyone gives to their
mistakes." -- Oscar Wilde

_______________________________________________________
Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

On Fri, 29 Feb 2008, Lars Marowsky-Bree wrote:

> On 2008-02-29T15:39:07, David Lee <t.d.leedurham.ac.uk> wrote:
>
> > > But if you can pretty it up and
--enable-pretty still works, sure.
> > No, I don't particularly want to get sidetracked
into its insides.  I was
> > simply wondering why, from the configure/make
perspective, it seems to be
> > a "special case".
>
> I _think_ this was related to the fact that it
overrides the CC
> variable; we need to have ccdv ready before we can
compile anything, but
> we obviously can't compile ccdv with ccdv already in
the CC setting.

Thanks, Lars.

What is 'ccdv' anyway? Could you jot down a brief
"executive summary" of
what it does?  Is it a compiler?  A "lint"-like
thing?  Etc.

At the very least, this discussion and the uncertainty
around it,
demonstrates that it a high quality comment is needed in the
code
(Makefile.am)...

Best wishes.  Have a good weekend.


-- 

:  David Lee                                I.T. Service    
     :
:  Senior Systems Programmer                Computer Centre 
     :
:  UNIX Team Leader                         Durham
University     :
:                                           South Road      
     :
:  http://www.dur.ac.uk/t.
d.lee/            Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.            
     :
_______________________________________________________
Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

On 2008-02-29T18:02:19, David Lee <t.d.leedurham.ac.uk> wrote:

> > I _think_ this was related to the fact that it
overrides the CC
> > variable; we need to have ccdv ready before we can
compile anything, but
> > we obviously can't compile ccdv with ccdv already
in the CC setting.
> 
> Thanks, Lars.
> 
> What is 'ccdv' anyway? Could you jot down a brief
"executive summary" of
> what it does?  Is it a compiler?  A
"lint"-like thing?  Etc.

Try it with --enable-pretty - it wraps gcc to make the build
less noisy
and, well, more pretty. (The longish gcc lines are only
shown when an
error actually occured.)


Regards,
    Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG
Nürnberg)
"Experience is the name everyone gives to their
mistakes." -- Oscar Wilde

_______________________________________________________
Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

On 2008-03-01T15:35:10, Lars Marowsky-Bree <lmbsuse.de> wrote:

> Try it with --enable-pretty - it wraps gcc to make the
build less noisy
> and, well, more pretty. (The longish gcc lines are only
shown when an
> error actually occured.)

BTW, David, I'm pretty sure your latest change has broken
this - ccdv
cannot be build using $(CC), as $(CC) requires ccdv to be
present.


Regards,
    Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG
Nürnberg)
"Experience is the name everyone gives to their
mistakes." -- Oscar Wilde

_______________________________________________________
Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

On Mon, 3 Mar 2008, Lars Marowsky-Bree wrote:

> On 2008-03-01T15:35:10, Lars Marowsky-Bree <lmbsuse.de> wrote:
>
> > Try it with --enable-pretty - it wraps gcc to make
the build less noisy
> > and, well, more pretty. (The longish gcc lines are
only shown when an
> > error actually occured.)
>
> BTW, David, I'm pretty sure your latest change has
broken this - ccdv
> cannot be build using $(CC), as $(CC) requires ccdv to
be present.

Hmmm... OK.  The reason I made that change was that someone
had reported
build failure on a system without 'gcc'; they had another
compiler but not
gcc.  Everything else in the build inherits
"$(CC)" through autotools.
So that person's build was mostly OK, but this explicit
"gcc" caused it to
fail at that point.

If you need to, feel free to back it out.

But might we (I?) be able to find a solution that lets
heartbeat build
using autotools-information and defaults, rather than
developer-based
assumptions such as "has gcc"?  (For instance, a
"$(something)" would be
preferable to an immutable 'gcc'.  Or some sort of #if-based
"Skip this
'ccdv' bit if 'gcc' isn't available".  Or similar...)

I don't really understand how 'ccdv' fits into the
development picture.
But is the idea to do a basic first build with the native
compiler
(typically 'gcc') to build 'ccdv' (typically with CC='gcc'),
then after
that a second build (or pseudo-build) with
'CC=/path/to/ccdv'?


At the least, could there be a comment above it that
sketches why this
particular item needs to be so different from everything
else?  Something
like the following would do:

 ###FIXME
 # Must use explicit 'gcc' because...
 # Must not be removed by 'make clean' because...

Then those of us who trip over it, and perhaps want to
investigate the
"FIXME" more deeply, are given a pointer towards
the rationale for the why
the unusual treatment currently exists.

All the best.


-- 

:  David Lee                                I.T. Service    
     :
:  Senior Systems Programmer                Computer Centre 
     :
:  UNIX Team Leader                         Durham
University     :
:                                           South Road      
     :
:  http://www.dur.ac.uk/t.
d.lee/            Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.            
     :
_______________________________________________________
Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

On 2008-03-03T14:31:36, David Lee <t.d.leedurham.ac.uk> wrote:

> > BTW, David, I'm pretty sure your latest change has
broken this - ccdv
> > cannot be build using $(CC), as $(CC) requires
ccdv to be present.
> Hmmm... OK.  The reason I made that change was that
someone had reported
> build failure on a system without 'gcc'; they had
another compiler but not
> gcc.  Everything else in the build inherits
"$(CC)" through autotools.
> So that person's build was mostly OK, but this explicit
"gcc" caused it to
> fail at that point.

Then, perhaps, they shouldn't use enable-pretty.

> But might we (I?) be able to find a solution that lets
heartbeat build
> using autotools-information and defaults, rather than
developer-based
> assumptions such as "has gcc"?  (For
instance, a "$(something)" would be
> preferable to an immutable 'gcc'.  Or some sort of
#if-based "Skip this
> 'ccdv' bit if 'gcc' isn't available".  Or
similar...)

Sure, if you can. But please, test the cleanups you make.
The current
code cannot work.

> I don't really understand how 'ccdv' fits into the
development picture.
> But is the idea to do a basic first build with the
native compiler
> (typically 'gcc') to build 'ccdv' (typically with
CC='gcc'), then after
> that a second build (or pseudo-build) with
'CC=/path/to/ccdv'?

Yes, ccdv is a wrapper which is prepended to the CC
variable, to
postprocess the output from CC.


>  ###FIXME
>  # Must use explicit 'gcc' because...
>  # Must not be removed by 'make clean' because...
> 
> Then those of us who trip over it, and perhaps want to
investigate the
> "FIXME" more deeply, are given a pointer
towards the rationale for the why
> the unusual treatment currently exists.

That's a good point, and feel free to add such comments when
you find
them! 

As a side issue, for the future, I'm not quite sure how much
effort is
worth spending on the heartbeat code base for portability,
at least if
the openAIS move is successful. I personally don't see
heartbeat being
ported to new architectures; other people's opinion might
differ
though.


Regards,
    Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG
Nürnberg)
"Experience is the name everyone gives to their
mistakes." -- Oscar Wilde

_______________________________________________________
Linux-HA-Dev: Linux-HA-Devlists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/