Vladimir Merzliakov
2005-Feb-14 23:40 UTC
[LLVMdev] Removing $(LLVM_SRC_ROOT)/autoconf dependensies in Stacker, llvm-java [PATCH]
Hi! In current LLVM CVS: llvm/projects/Stacker/Makefile.common.in llvm/projects/sample/Makefile.common.in llvm-java/llvm-java/Makefile.common.in have line: include $(LLVM_OBJ_ROOT)/Makefile.common that have line: include $(LLVM_OBJ_ROOT)/Makefile.config (also $(LLVM_OBJ_ROOT)/Makefile.config used in llvm-test/Makefile.config.in) and llvm/Makefile.config.in have lines: INSTALL_SH := $(LLVM_SRC_ROOT)/autoconf/install-sh MKDIR := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs But all this projects (LLVM, Stacker, sample, llvm-java) have autoconf/install-sh and autoconf/mkinstalldirs in own sources. I think at building, for example, llvm-java use llvm-java/autoconf/install-sh is more correct (synchronized version with other autoconf files and configure in project sources) Is patch replacing INSTALL_SH := $(LLVM_SRC_ROOT)/autoconf/install-sh MKDIR := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs by INSTALL_SH := $(PROJ_SRC_ROOT)/autoconf/install-sh MKDIR := $(PROJ_SRC_ROOT)/autoconf/mkinstalldirs acceptable? LLVM (including Stacker, sample), llvm-java build and installed with patch and without problems. llvm-test have same install-sh and mkinstalldirs files as Stacker. Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.config.in.patch Type: application/octet-stream Size: 572 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050215/2e68dbb6/attachment.obj>
Reid Spencer
2005-Feb-15 00:39 UTC
[LLVMdev] Removing $(LLVM_SRC_ROOT)/autoconf dependensies in Stacker, llvm-java [PATCH]
Personally, I don't think LLVM projects should need much in the way of autoconf stuff. They certainly don't need to replicate things like install-sh and mkinstalldirs. I'd vote for taking these out of the projects rather than making the makefiles deal with them. I think in most cases these are just historical artifacts that have been with the projects since long before the new Makefile.rules of last fall. More below .. On Mon, 2005-02-14 at 15:40, Vladimir Merzliakov wrote:> Hi! > > In current LLVM CVS: > > llvm/projects/Stacker/Makefile.common.in > llvm/projects/sample/Makefile.common.in > llvm-java/llvm-java/Makefile.common.in > > have line: > include $(LLVM_OBJ_ROOT)/Makefile.common > > that have line: > include $(LLVM_OBJ_ROOT)/Makefile.config > > (also $(LLVM_OBJ_ROOT)/Makefile.config used in llvm-test/Makefile.config.in)This is all quite normal. Note that llvm-test is a little bit weird because it does not use $(LLVM_OBJ_ROOT)/Makefile.rules, it has its own Makefile.rules> and > > llvm/Makefile.config.in have lines: > > INSTALL_SH := $(LLVM_SRC_ROOT)/autoconf/install-sh > MKDIR := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs > > But all this projects (LLVM, Stacker, sample, llvm-java) have > autoconf/install-sh and autoconf/mkinstalldirs in own sources.Which they probably shouldn't have. I'd vote for removing these files from the projects.> I think at building, for example, llvm-java use > llvm-java/autoconf/install-sh is more correct (synchronized version with > other autoconf files and configure in project sources)I think that it just leads to confusion. LLVM should provide the core set of tools (mklib, install-sh, mkinstalldirs, etc.) needed by the makefile system (since LLVM owns the makefile system). LLVM projects that want to use this system should use its facilities and not override them. If someone doesn't want to do that, then it shouldn't be regarded as an LLVM project (in the makefile sense).> Is patch replacing > > INSTALL_SH := $(LLVM_SRC_ROOT)/autoconf/install-sh > MKDIR := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs > > by > > INSTALL_SH := $(PROJ_SRC_ROOT)/autoconf/install-sh > MKDIR := $(PROJ_SRC_ROOT)/autoconf/mkinstalldirs > > acceptable?Its acceptable but I don't think its what we ultimately want to do. I'd rather everyone use a consistent version of install-sh and mkinstalldirs (the ones provided by llvm/autoconf) rather than every project rolling their own.> LLVM (including Stacker, sample), llvm-java build and installed with patch > and without problems. > llvm-test have same install-sh and mkinstalldirs files as Stacker.Sure, my argument isn't current correctness, its future correctness. What happens when we update the LLVM tools in the future and they are no longer compatible with the ones in the projects? The answer is that the projects break. If we make the projects use the new tools (as currently done with LLVM makefiles), we limit the number of things that have to change and ensure that we don't break the projects after changes. On a larger scale, I have toyed with the idea of making the LLVM Makefile system just a separate public domain software project that anyone can use. But, not sure how everyone would feel about that. Reid. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050214/69d11e1e/attachment.sig>
Chris Lattner
2005-Feb-15 04:53 UTC
[LLVMdev] Removing $(LLVM_SRC_ROOT)/autoconf dependensies in Stacker, llvm-java [PATCH]
On Mon, 14 Feb 2005, Reid Spencer wrote:> Personally, I don't think LLVM projects should need much in the way of > autoconf stuff. They certainly don't need to replicate things like > install-sh and mkinstalldirs. I'd vote for taking these out of the > projects rather than making the makefiles deal with them. I think in > most cases these are just historical artifacts that have been with the > projects since long before the new Makefile.rules of last fall.I agree.>> llvm/Makefile.config.in have lines: >> >> INSTALL_SH := $(LLVM_SRC_ROOT)/autoconf/install-sh >> MKDIR := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs >> >> But all this projects (LLVM, Stacker, sample, llvm-java) have >> autoconf/install-sh and autoconf/mkinstalldirs in own sources. > > Which they probably shouldn't have. I'd vote for removing these files > from the projects.Agreed. If projects choose to use our makefiles, they can know and use the main copies of these that LLVM provides.>> I think at building, for example, llvm-java use >> llvm-java/autoconf/install-sh is more correct (synchronized version with >> other autoconf files and configure in project sources) > > I think that it just leads to confusion. LLVM should provide the core > set of tools (mklib, install-sh, mkinstalldirs, etc.) needed by the > makefile system (since LLVM owns the makefile system). LLVM projects > that want to use this system should use its facilities and not override > them. If someone doesn't want to do that, then it shouldn't be regarded > as an LLVM project (in the makefile sense).However, projects should continue to be able to have their own configure scripts. It would be nice if this was optional though! :)> On a larger scale, I have toyed with the idea of making the LLVM > Makefile system just a separate public domain software project that > anyone can use. But, not sure how everyone would feel about that.If it didn't make things any uglier, I personally wouldn't have a problem with it. They should be significantly refactored first though. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
Possibly Parallel Threads
- [LLVMdev] Removing $(LLVM_SRC_ROOT)/autoconf dependensies in Stacker, llvm-java [PATCH]
- [LLVMdev] Removing $(LLVM_SRC_ROOT)/autoconf dependensies in Stacker, llvm-java [PATCH]
- [LLVMdev] Removing $(LLVM_SRC_ROOT)/autoconf dependensies in Stacker, llvm-java [PATCH]
- [LLVMdev] Removing $(LLVM_SRC_ROOT)/autoconf dependensies in Stacker, llvm-java [PATCH]
- [LLVMdev] Add ability for external projects use for build installed version LLVM [PATCH]