[MonoDevelop] Autotools integration?
Tue, 14 Dec 2004 21:47:19 -0800
On Tue, 2004-12-14 at 21:13 -0500, Miguel de Icaza wrote:
> Hello Alexandre,
> I agree with your sense of urgency and your sense that something
> must be done about it.
> My personal opinion is that building on top of the auto-tools means
> that you are building on a shaky foundation, and a foundation on which
> you will end up writing tools that try to parse (and fail) the language
> used by automake/autoconf which are not really going to be parseable,
> they will always break on some condition.
> Leaving alone the editing capabilities, the other issue is that
> autotools are all very fragile: they need specific versions to work with
> each other, and they often break. So all in all, I think that going
> this path is a path of failure.
> My proposal to depend exclusively on pkg-config means that libraries
> that are mature enough will have to provide it and its is both parseable
> and detectable. The autotools are designed to help you write portable
> code that will run on BSD 4.2 on a VAX or your most modern Linux distro.
> I think we can safely say that Mono wont run on anything primitive,
> and we might as well just ignore anything older.
> Now, the important bit is to get the work started and grow it
> organically. After seeing so many attempts at coming up with an all
> encompassing solution for the last six years, I do not think we will be
> able to foresee everything that is needed in advance.
> Hence organically grown, pkg-config based, and the configure and
> Makefiles generated from our internal XML "Solution" format is the right
> path to go.
There is already the beginnings of an implementation of this in
MonoDevelop. However, to not conflict with existing makefiles, the
makefile created is named Makefile.SolutionName and is easily runnable
via a make.sh file created in your toplevel directory.
There are many bits and pieces missing with this method, and a lot of
work needs to be done in order to make it not suck. Also, MonoDevelop
does this in a somewhat poor way, that would basically require
reimplementation for any project that isnt C#. There is most likely a
better way to handle all of this.
dist/distcheck actions are not supported, and multi-startup solutions
are not supported.
So basically, this code exists, and is relatively usable, at least as a
starting point for a more robust solution. Any/All patches to this
functionality would be appreciated, reviewed, and most likely accepted.