[MonoDevelop] Re: More detailed build response

[Miguel de Icaza]

Hello,

> //I assume by this you also mean probing for required assemblies.
> //This is something we should add some automation for. For example, if
> //I add gtksourceview-sharp as a reference to my project, the build
> //system needs to be smart enough to add this to my build requirements
> //
> //What are we going to be doing to support existing auto* build
> //systems. Will there be an easy way to run make on a certain
> //directory?
> 
> We want applications to be self contained, so running an application
> within MonoDevelop will not cause a full make/make install process to be
> triggered before it can be executed. 

Yes, that is what it means: to probe for functionality.

I have chosen pkg-config to probe, since it is something that the
configure script that we would generate could easily probe for, and
integrates with the existing probing systems.

The makefiles on each directory would be self-contained, so you can type
`make' to build that directory.

> //Will this be accomplished with something similar to the build/
> //directory in MD, or will we be doing something different?

I honestly need input here.  I would personally leave the binaries on
each directory, but this might not be ideal.

A few scenarios:

	Visual Studio builds into Bin/Debug and Bin/Release, 
	one per project.  I do not quite like this setup, I find it
	too nested for my taste.

	Using a common directory for placing all the files like MD,
	this seems fairly clean, but complicates the `run' target.

	Using the current directory to generate the .exe or .dll seems
	the most Unix-y way of doing things.

> //I think we should be adding a third file for this. Another thing
> //to keep in mind with adding this info to the cmbx file is the
> //ability to reuse projects.
> //
> //Projects themselves should be self contained and know how to build
> //themselves, so that you can use them from multiple solutions.

I honestly do not know enough about .cmbx files, or the existing setup,
can you present what we have today?

> //I assume you mean that we can write one (huge) configure script
> //that we package with MD and then copy into the solutions top
> //level folder. If so, what are we planning on writing this in?
> //Also, are we going to use standard configurelike switches, such
> //as --prefix, --disable-xxxx, --enable-xxxx, etc.
> 
> //Will this configure script allow for complicated conditional
> //switching? (ie, if this lib is present, build yyy, if not, check
> //for this other library, and do zzz, and if nothing is there, error
> //out with this info).

Well, the configure script is automatically generated from the project
options: optional dependencies listed, libraries required, and projects
in the solution.  

The resulting output should be plain shell.   The resulting script
should use configure-like scripts, it only makes sense.

I do not know if we want to do more complicated conditional building
beyond a simple layer, because UI wise, we would enter research land,
and my intent is to have something working first.

Doing a setup that handles every possible combination in the world is
going to be a gargantuan task, so my focus on this design is to address
common setups, not every setup.

> //What about when you need to use C, as many projects do (MD included)
> //Will we attempt to rewrite auto* for them, or encourage the use of
> //auto* seperately and add hooks?
> //
> //The ability to compile C is a must-have for this build system, as
> //designing something that is unable to self host is not good.

If they can be built completely with the pkg-config results, that can be
handled.  If not, I would encourage the C components to be split into a
separate module, that can be pkg-config for, and that has all the
autoconf/automake bells and whistles it needs.

> //Why not allow for more targets? make dist seems reasonable, as does
> //make test for running tests. Potentially allowing people to append
> //content to the makefiles and add their own should be supported.

I guess it could be added, I do not see why not (other than UI issues,
and obscure side effects).

> 
> //I assume there will be support for flagging files as 'dont build'?

Can you give me an example?

> //I assume there will be gui for all this, where will this gui be
> //located?

This is autogenerated.  I do not understand your question.

> //Will we add support for libraries that this build system produces
> //to automatically produce an up to date .pc file and install it?

Fantastic idea.


> //What exactly is the point of this file? to basically provide
> //#if ENABLE_XXXX support?

Yup.

> //What about make distcheck, considering that unless we rewrite auto*
> //for the bundled c code, people using auto* for c might want to at
> //least allow that code to be make distcheck'd somehow
> //
> //Also, i assume this will output a proper .tar.gz will all the
> //needed stuff.

make distcheck is required when a human is required to intervene to
maintain the files that make up a distribution, to ensure that the human
did not make a mistake.

If we are not packaging things completely, it would be a build system
bug, not a user bug, so we must fix it ourselves.

That being said, we could have a target like `distcheck' aimed as a
regression test for our build setup.

> //personally, i think this is *completely* outside the scope of a 
> //build system.
> //potentially providing hooks for this would be more than enough
> //as every packagers requirements are completely different, and
> //9 times out of 10, people dont package the apps they develop
> //beyond simple tarballs.

Open Source developers do not package anything beyond simple tarballs.

Proprietary developers (which we hope to attract) would like to have a
way of building binary packages.

Either RPM or some other form of self-installable software, and I think
it is a big plus.

Miguel