This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Most of the GNU open-source apps use the configure-make scheme, which means that they are supplied with a Makefile.in file that is actually a template for resulting Makefile, and a configure script that generates a system-specific Makefile from Makefile.in with results of a number of tests. The Makefile.in and configure script are generated by GNU Autoconf/Automake bundle.
It's a good idea and we have already an issue file on this :http://www.netbeans.org/issues/show_bug.cgi?id=74753. We kind of support this already. All you would need to do is to change the pre-build target in the master makefile to something like: .build-pre: cd <open_proj_location>;\ if [ ! -r Makefile ]; \ then ./configure; \ fi then it would check whether configure has been run before building the project. We should probably add add a choice in the wizard to automatically add this to the master makefile. --thomas Nikolay Molchanov wrote: > Thomas, > > I was going to ask about it many times :-) Can we implement some > kind of support for open source projects? What I mean is: usually > open source projects have "configure", and the build process is: > > ./configure > make > make install > > Obviously "configure" requires several binaries to be in PATH, > and it would be great if we have some kind of "Open Source" project, > which is aware of "configure", these necessary binaries, and probably, > in future, will be able to download the sources from Internet, extract > them, create "Open Source" project, create makefile, that will set PATH, > run "./configure", "make", "make install", so that user will not need > to run shell in a terminal window, cd to .../ and run ./configure, ... > > I think this would be a nice feature, and it will differentiate us > from many competitors. What do you think?
Nik: I would suggest to write it using "make" language :-) .build-pre: $(open_proj_location)/Makefile CONFIGURE_OPTIONS= $(open_proj_location)/Makefile: $(open_proj_location)/configure cd <open_proj_location>; \ ./configure ${CONFIGURE_OPTIONS} > > We should probably add add a choice in the wizard to automatically add > > this to the master makefile. Yes, but this is a part of the solution. It is also very important to make sure that PATH is set properly (which means all necessary binaries will be found). This requires some kind of intelligence to check if they are in user's PATH, and if not to check if they are installed somewhere, and if not, to download and install them. It is not necessary to do these checks beforehand, but if the build failed at step "configure", it would be very helpful to analyze the build problem, and help user to fix it.
Please let me review the solution and the fix before it gets committed....
Give back issue to evaluation to project system Guru.
Seems like the 'standard' gnome autoconf/automake sequence in linux starts with -- ./autogen.sh followed by ./configure (with or perhaps without a --PREFIX option) followed by make followed by make install (perhaps with a --PREFIX option) although there may be additional issues around the presence or absence of GNU libtool. This tool seems to address some of the PATH issues noted earlier. Should be fairly easy to create a prebuild script covering these possibilities by someone more adept at scripting than I. The approach suggested is a wizard that includes the template: -- prefix [allow user to decide if testing or standard prefix] -- if [-f autogen.sh] then ./autogen.sh ./configure --PREFIX=[prefix if supplied] make make install elif [-f configure] ./configure --PREFIX=[prefix if supplied] make make install elif [-f Makefile] make make install --PREFIX=[prefix if supplied] fi