This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: mknetrel builds Guile #3: libtool


On Tue, Jul 09, 2002 at 04:16:03PM -0400, Charles Wilson wrote:
>>Let keep the conversation about building a cross-compiler automatically 
>>going.  I think CGF is being rather stubborn about it  and doesn't see 
>>the potential benefits for the end user. 
>
>No need to be confrontational, Nicholas...

Yeah, either I'm being stubborn or you're not getting the point,
Nicholas.  Guess which I think it is?

>>What probably should happen is the build cross environment script
>>should be in a separate cvs tree and maintained apart from mknetrel.
>>When things get properly situated, then we could release a package that
>>contains these scripts for people to download and use as they see fit.
>>Perhaps that could be build method #3.
>
>You're probably talking about a linux/solaris/hpux/whatever "package"
>that consists of all of the cross compiler bits for a cygwin-target
>environment.
>
>Why does this need to be driven by mknetrel?

Which is the basic question.  If you are using mknetrel to build on
linux then you need linux cross tools.  That's a given.  The fact that
mknetrel needs the linux cross tools doesn't mean that mknetrel has to
build the linux cross tools any more than it means that mknetrel needs
to be able to build linux or bash or awk.

It's really simple: the input of mknetrel is package source.  The output
of mknetrel are the package tarballs.  It's a pipe without a tee.

I have already suggested that a separate package would be the way to
go with this:

"If someone wants to contribute YA cross building script then that's
fine."

I'm not unsympathetic to the people who find building a cross build
environment difficult but I don't think that the environment belongs in
the mknetrel repository.

I do like the idea of just making an RPM or .deb file available.
That seems like the right way to go to me.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]