RE: makeflags, cross-compiling, and col

[Suhaib Siddiqi <ssiddiqi at inspirepharm dot com>]

I cannot be really of much help for a cross-compilation.
There is a --unix rule in Cygwin.cf file too.  You can have a look at it.

Suhaib

> -----Original Message-----
> From: jimk [mailto:jimk@scitechsoft.com] 
> Sent: Wednesday, June 06, 2001 1:55 PM
> To: Suhaib Siddiqi; cygwin-xfree@cygwin.com
> Subject: RE: makeflags, cross-compiling, and col
> 
> 
> On 1 Jun 2001, at 19:12, Suhaib Siddiqi wrote:
> 
> > I have never compiled Xfree86 with a cross-compiler under Cygwin.
> > Therefore I do not guarantee my suggestions will work.  I 
> am certain you
> > Will need to do a lot of hacking.
> > 
> 
> Thanks for the help.  I've come that that same conclusion.
> 
> > > 
> > > How can I get rid of the --unix in Makeflags?  I'm trying 
> to do make
> > > World and nested down in a bunch of the subdirectories, when
> > > make gets to this section of the Makefile,
> > > 
> > > $(ONESUBDIR)/Makefile:
> > >         @for flag in ${MAKEFLAGS} ''; do \
> > >         case "$$flag" in *=*) ;; *[n]*) executeit="no";; 
> esac; done; \
> > >         cd $(ONESUBDIR) && \
> > >         if [ "$$executeit" != "no" ]; then \
> > >         $(IMAKEPREFIX)$(IMAKE) -I$(IMAKEPREFIX)$(IRULESRC)
> > > $(IMAKE_DEFINES) -DTO
> > > PDIR=$(IMAKETOP) -DCURDIR=$(ONECURDIR)$(ONESUBDIR); \
> > >         fi;
> > 
> > 
> > this rule is in xc/config/xc/Imake.rules.  
> > 
> > @MakeFlagsToShellFlags(n,executeit="no"); \                     @@\
> >  cd $(ONESUBDIR) && \                                            @@\
> >  if [ "$$executeit" != "no" ]; then \                            @@\
> > 
> > If you fix the Imake.rules file, your Makefiles should be 
> generated without
> > --unix makeflags?
> > 
> > > 
> > > it basically sees the --unix in MAKEFLAGS, sets executeit="no" and
> > > then doesn't run Imake to create the Makefile in each of the
> > > subdirectories.  I don't know enough about makefiles yet to know
> > > why, so here is one of my questions.
> > > 
> > > What is the real intention of that?  Just ignoring that 
> case statement
> > > lets the Makefiles get built, which is obviously the 
> ultimate intention
> > > since if they didn't need to be built, doing a make World wouldn't
> > > choke with the statement that it couldn't find a rule to 
> make clean in
> > > that subdir.
> > 
> > I do not know what is the real intention of that.  Perhaps 
> Alan can shed
> > Light on it?
> > 
> 
> Hmmm.  Well, I see how I can hack that Imake.rules file to always 
> ignore that --unix makeflag (or all makeflags), but I don't see how I 
> can get --unix 'out' of the makeflag so the Imake.rules file 
> won't have 
> that problem.  I'm just a little leary about hacking 
> functionality out of 
> the process without understanding why someone else put it in (and 
> what the implications of hacking it out really are).
> 
> 
> > 
> > > 
> > > I'm trying to build under cygwin, but I'm using a gcc 
> cross-compiler
> > > targeting linux.
> > > 
> > > My other problem (well, one of them) is that I was having 
> a hard time
> > > convincing the Imake process to actually use the cross-compiler.
> > > I've seen the few examples, but I ended up just setting my cross-
> > > compiler as the default compiler and the few things that needed to
> > > be compiled native (like imake, makekeys, makestrs) I compiled
> > > separately and removed the compile references from the make
> > > process.  This seems to have worked, but it seems less clean than
> > > running a real multi-compiler environment and I'm not 
> sure it is an
> > > adequate solution.  It also still throws up a number of dialog box
> > > errors in certain spots similar to what I get when I try 
> to execute a
> > > linux program on my win2k machine from within bash.  I haven't
> > > figured out where it is yet, but it's right after it does 
> a ranlib on some
> > > lib and then an rf -f on that same lib. Would I be better 
> off using a
> > > true multi-cross-compiler environment?  And if so, how?  When I
> > > was doing it, it always pulled in the cygwin.cf file and 
> what I really
> > > need is for it to pull in the linux.cf file (which it 
> does in my hacked
> > > version)?
> > 
> > 
> > Under Cygwin it supposed to pickup cygwin.cf. I am not a 
> cross-compiler
> > expert therefore I do not know what to tell you about 
> ranlib etc errors.
> > 
> Yeah, unfortunately I'm not either.  I am able to get through to the 
> end by just pushing on through the dialog boxes, so although 
> extremely annoying, it's not a complete showstopper at this 
> point.  It 
> would be nice to have it flow smoothly though.  Anybody else out 
> there have any thoughts?
> 
> > > 
> > > Lastly, it was also choking because it couldn't find the 
> col utility
> > > which I don't find in cygwin but I do find in linux.  I 
> managed to use
> > > a pair of jumper cables and arc around that issue, but I'd like to
> > > know what the proper way of handling this is.  Get the sources for
> > > col and recompile under native cygwin? (where?)  Patch in cat in
> > > place of col which is what it looks like is done for os2?
> > 
> > You will need to port col utility.  I am sure sources 
> should be on Linux
> > SRMS CD.  Extract the SRPM file on a linux machine with 
> rpm2cpio.  It 
> > Should give you a *.tar.gz file, move it to your machine 
> where Cygwin is
> > intsall, and port it to Cygwin.  You may ask Cygwin mailing list
> > cygwin@cygwin.com if someone has arleady ported it to Cygwin.
> > 
> > 
> > Suhaib
> > 
> 
> Thanks for the help.
> -Jim
>