Re: [Chicken-users] CMake tarballs

[Brandon J. Van Every]

felix winkelmann wrote:
> On 7/31/06, Brandon J. Van Every <address@hidden> wrote:
> > >
> > > Sorry, but why do we need two different kinds of binary distributions?
> >
> > This seems to be confusing the issue.  I thought the parlance was, a
> > Chicken tarball is not a binary, it is a source tree with .c files that
> > does not require Chicken in order to build it.  The CMake build has this
> > capability now.  However, it generates a different tarball than
> > ./configure does.  It doesn't put .c files in the same places; this is
> > necessary to support CMake's two-stage bootstrapping and
> > out-of-directory build capabilities.
>
> Oh, damn. Yes, of course you where talking about tarballs. I should
> pay more attention.
>
> Is there *some* way to have a single tarball layout?

Sure.  I suggest creating /boot/*.c.in files as the CMake build does.  
That way, people won't get confused about .c files in their toplevel 
directory, whether those were built in-directory or came with the 
tarball, etc.

> In what directories
> do you need to put the files? I don't want different tarballs for 
> different
> build tools, that's silly.

No it is not silly, because...

> So we have to make them equivalent and
> distribute a single one.

...when you say "we," do you mean "you?"  Unless you are willing to work 
on ./configure, or you can goad some other ./configure expert into doing 
it, these builds ain't gonna merge.  I'm not a ./configure expert and 
I'm not going to become one.  I'll handle stuff that needs to happen on 
the CMake side, that is easy for me.  But learning ./configure in detail 
is a complete waste of my time and defeats the purpose of my last 9 
months.  If I had any intention of dealing with ./configure that much, I 
would have done it 9 months ago.

It would be quite sensible to distribute 2 builds to save work.  It's 
sensible to have no conflation of issues, i.e. nobody half-building with 
./configure then switching to CMake because something went wrong on 
MinGW, then half-arsing the whole thing in their bug report.  No getting 
confused about which set of directions to follow.  No deadcode paths, 
where say the distribution/release.setup code is being exercised, the 
dist.cmake code isn't, and the CMake build is always being broken on 
check-ins because it's not being exercised regularly. 


Cheers,
Brandon Van Every