RE: [omniORB] Minor patch to windows build

Copy the list in your replies (or reply-all), that way we can get
everyone's insight...
  
> Oh, I missed that.  You already have some SCons builds which work in
> windows.  Could you possibly send them to me so I can see what you
have
> so far?
> 
> As for the autoconf stuff, I've found that you rarely need to generate
> a config.h if you use SCons in a particular way.  I've have my builds
> setup so they are very clean and easy to port to new systems (I can
get
> a new system up in about 10 minutes).  What I do is I have a single
> SConstruct file which defines the targets, but which delegates to a
> platform specific SConscript file (like, netbsd1.SConscript, etc.) to
> setup things like weird tools locations, library and include points,
> and any defines which are needed.
> 

First off, it does sound nice and clean, but...

The problem with this is the idea of platform/compiler combos. If you
look at omni's current configure.ac, it has macros to test obscure parts
of the compiler, header locations, type sizes, etc. This allows a
developer to set CC='some nonstandard compiler' and the configure script
figures out everything about that compiler and goes on with the build. I
personally like this feature a lot.

To do the same with your proposed method I would need a
win32.Sconscript, but also a vc6.Sconscript, vc7.Sconscript and
mingw.Sconscript. To support the compilers I use on that platform. This
doesn't sound too bad until you look at all the unices, and all there
compilers and all those compiler's versions.

On the other hand, I believe all the logic necessary to build the files
I speak of is laid out in the "old" build system of make files;
therefore we would just have to convert logic.

I would like to try using/copying the autoconf method, and if/when that
fails/too_much_work, I think this method is a great second choice.

> You should try grabbing:
> 
> :pserver:[email protected]:/cvsroot/obversive
> 
> With CVS and take a look at the build I have there to see how it
works.
> 
> Now, my next step was to have a very simple template setup which would
> be run from the platform specific SConscript file, and that would
> generate the config.h based on the setting there.  Let's say I have
> this layout:
> 
> SConstruct
> src/
> config/
> 	win32.SConscript
> 	config.h.tpt
> 
> What would happen then is, the SConstruct would run, it would then run
> the win32.SConscript to configure any tool weirdness, and then the
> config.h.tpt would be parsed as a python statement to create the
> config.h file.
> 
> With that, you then have everything you need and the build is super
> clean.
> 
> Sound good?
> 
> Zed
> 
> 
> On Wednesday, April 9, 2003, at 01:13 PM, Kevin Wooten wrote:
> 
> > Yes!
> >
> > I have wanted to finish my omni scripts, which are very rudimentary
and
> > currently windows only, unfortunately a good solution for the
config.h
> > problem was my sticking point.
> >
> >> From my initial examination I came up with two solutions for this
> > problem; 1) somehow drive autoconf (or its macros).
> > 2) replace all the functionality with our own.
> >
> > If there are any clever ideas for solving this problem, let me know.
> >
> > -KW
> >
> > P.S. - I have moved this to omniorb-dev, where it belongs.
> >
> >> -----Original Message-----
> >> From: Zed A. Shaw [mailto:[email protected]]
> >> Sent: Wednesday, April 09, 2003 12:13 PM
> >> To: Kevin Wooten
> >> Subject: Re: [omniORB] Minor patch to windows build
> >>
> >> Kevin,
> >>
> >> I've done this before in my projects.  I have a very clean design
for
> >> my SCons builds and have managed to create two projects that I am
able
> >> to port between various types of Linux, NetBSD, and Mac OSX.  I did
> >> approach the SCons team before about making a config.h equiv., but
> > they
> >> were not too interested.  If you read my previous e-mail, I may be
> >> attempting an SCons build myself.  Care to join forces?
> >>
> >> Zed
> >>
> >>
> >> On Wednesday, April 9, 2003, at 11:04 AM, Kevin Wooten wrote:
> >>
> >>> Even replace autoconf?? I know you are open to the idea of using
> > scons;
> >>> I have built some scons scripts to build omniorb, the only problem
I
> >>> have is that the autoconf support macros are not easily
reproducible
> > in
> >>> scons. What is needed is a replacement for building a configure.h
> > from
> >>> scons or Python. I am not sure if this is on their list, but I
would
> > be
> >>> open to finishing it if you are interested; I could even
collaborate
> >>> with the scons team if they like the idea.
> >>>
> >>>> -----Original Message-----
> >>>> From: Duncan Grisby [mailto:[email protected]]
> >>>> Sent: Wednesday, April 09, 2003 6:53 AM
> >>>> To: Mark Hammond
> >>>> Cc: [email protected]
> >>>> Subject: Re: [omniORB] Minor patch to windows build
> >>>>
> >>>> On Wednesday 9 April, "Mark Hammond" wrote:
> >>>>
> >>>>> I have made a simple patch to the build system, so that omniidl
> > will
> >>>> compile
> >>>>> on windows from a Python source tree (rather than just a binary
> >>>> installed
> >>>>> version).
> >>>>
> >>>> Thanks for that. I've checked it in to CVS.
> >>>>
> >>>> [...]
> >>>>> Would patches that removed some hacks via cygpath and/or
autoconf
> > be
> >>>>> welcomed, even if they were "one-step-at-a-time" type patches?
I
> >>> guess
> >>>> it
> >>>>> would mean updating your "minimal cygwin".  A potential future
win
> >>> is
> >>>> that
> >>>>> it would open the door to using the via the cygwin Python
builds.
> >>>>
> >>>> I'm not sure whether it's worth the bother. The whole build
system
> > is
> >>>> a terrible mess, built out of a combination of several earlier
> >>>> systems, with all sorts of hacks to work around problems and
> > platform
> >>>> differences. I think tweaking it even more, especially if it
means
> >>>> having to change the current minimal cygwin thing, is only really
> >>>> compounding the problem.
> >>>>
> >>>> I think that by far the best thing to do is to throw out the
whole
> >>>> build system and replace it with something simpler and cleaner. I
> > was
> >>>> intending to do that for omniORB 4.0, but it never happened. I
> > really
> >>>> do want it to happen for 4.1.
> >>>>
> >>>>> Oh - and finally, it seems the devel branch is currently fails
on
> >>>> Windows
> >>>>> (well, 12 hours ago anyway!) :)  That isn't a problem for me
> > though,
> >>> I'm
> >>>> on
> >>>>> 4.0.1.
> >>>>
> >>>> That was due to a silly bug in reusing a variable name in a for
> > loop.
> >>>> It's fixed now.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Duncan.
> >>>>
> >>>> --
> >>>>  -- Duncan Grisby         --
> >>>>   -- [email protected]     --
> >>>>    -- http://www.grisby.org --
> >>>> _______________________________________________
> >>>> omniORB-list mailing list
> >>>> [email protected]
> >>>> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> >>> _______________________________________________
> >>> omniORB-list mailing list
> >>> [email protected]
> >>> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> >>>
> >>>
> >> -----
> >> Zed A. Shaw
> >> http://www.zedshaw.com/
> >
> >
> -----
> Zed A. Shaw
> http://www.zedshaw.com/