[Mono-list] type-reflector makefile
15 Jan 2003 22:47:09 -0500
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
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
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.)
* 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.