Re: Restructuring GDK for 1.3

"Shawn T . Amundson" <> writes:

> > > The primary problem with this is all the beos backend is 
> > > necessarily done making use of C++ code.  Autoconf doesn't 
> > > like compiling C code with a .c extention, making this method 
> > > a bit more a pain.  We can force usage of g++ for .c files, 
> > > but I don't really want to compile all the files (like gdkrgb) 
> > > with g++ if we can prevent it.  And we definately want libgtk 
> > > compiled with gcc.
> > 
> > Thanks for pointing out this issue ... I hadn't really 
> > thought of it and i.
> > 
> > There is nothing stopping one from having
> > a beos/ file in my scheme. I'd sort of like
> > to keep the practice of having a gdk/gdkwindow.c file
> > there, though it is a bit silly if they end up being
> > empty.
> The problem with having gdk/beos/ is that autoconf doesn't
> really like having source files in different directories.  
> Currently I have all the files in gdk/beos/ and it's own 
> and it copies gdkrgb.c and such (I don't remember if that is the only 
> one) into the beos/ directory before compiling.  It adds in .. and 
> ../.. for include paths so headers remain untouched.
> The problem with this is that beos/ is a subdir of gdk then and nothing
> gets compiled in the gdk directory.  Since automake doesn't like 
> conditionally compiling things in a directory, this won't work well
> except as I have deleted lots of stuff from gdk/ currently.
> Perhaps the best thing would be to copy the source files from beos/ to
> gdk/, or link them or something.  (They are all .cc files.) I don't know 
> how dependancies would work if they were linked though.
> Or we could cp gdkwindow.c to for beos and continue as
> you described previously.  (I think I prefer this.)

I'd like to avoid any sort of copying or linking. 

After fooling around with this, I think the best way to do
this is to have 


Then have beos/ build a libtool convenience 
library of the .cc files under beos and link that into which is created in the main gdk/ directory.

I've tried this with a little sample setup and it seems
to work OK.

Does this sound reasonable?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]