[Mono-list] type-reflector makefile

[Jonathan Pryor]

I feel like we're discussing solutions to a problem which isn't entirely
solvable.  (At least, not solvable without the presence of autoconf
scripts and similar mechanisms.)

In an ideal world, I want the makefile for type-reflector to
automagically build the most sophisticated front-end that the build
machine supports.  If the build machine supports Gtk#, it's compiled
in.  If it doesn't support a GUI, it gets a console.

Furthermore, if the build machine changes to support (or drop support)
for a front-end, type-reflector would be rebuilt to add/remove the
appropriate front-end.

That's where I want to be.  I don't think that's possible (short of
moving the front-ends into their own DLLs...).*

At present, the build machine could change drastically, and if the
type-reflector source isn't updated, it won't get re-built, so it won't
support the latest-and-greatest front-end that the build-machine
supports.  However, at least there is an opportunity for type-reflector
to be rebuilt (and thus check the capabilities of the build machine)
when type-reflector is updated in CVS.

The problem with using marker files is that once a compilation fails, it
will never be re-attempted (unless a "make clean" is performed). 
Personally, I don't like this idea, as it effectively states "the build
machine will never change, so don't try giving me a nice interface."  I
suppose logic could be added to delete the marker files after a given
time interval, but my makefiles are complicated enough as it is...

I don't fully understand one of your statements, when you say: "Should
the third attempt not build a second time if it succeeded the first
time?"

If I understand you correctly, then you're asking for the current
behavior.  If it builds console-only output the first time, and then you
rebuild (without an intervening clean), then it shouldn't be rebuilt. 
(Unless the type-reflector source has been updated in CVS, which would
cause a full rebuild of type-reflector, resulting in three compiles,
assuming the build machine hasn't changed.)

 - Jon

* What's wrong with moving the front-ends into their own DLLs?  Time. 
School is starting, so the time I'll have for type-reflector (much less
anything else in mono, aside from this mailing list) will be greatly
diminished.  I'll be hacking on a pascal compiler for HYPOMAC instead.

Plus, I fear (perhaps incorrectly) the issues with DLL placement.  For
.NET, unshared DLLs need to be in the same directory as or a
subdirectory of the executable.  The addition of DLLs to the $prefix/bin
directory would probably look "weird," cause concern by others ("why
aren't they in the $prefix/lib directory?"), and cause more difficulties
than I want to bother with right now.

On Wed, 2003-01-15 at 22:20, Nick Drochak wrote:
> | Yeah, this was mentioned to me late last week.  It's been (somewhat)
> | fixed in CVS.  In particular, the problem where it is always rebuilt,
> | even when no files have been changed, has been fixed.
> 
> Maybe the first two attempts that fail could create a marker file (via
> touch?) so that they don't try again.  Should the third attempt not build a
> second time if it succeeded the first time?
> 
> Nick D.
>