llvm dev - Feb 2005 - [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/

On Mon, 2005-02-14 at 20:53, Chris Lattner wrote:
> 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.
Okay, I'll make that happen :)
> >> 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.
Right.
> 
> >> 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! :)
It already is optional. Projects don't even have to have a
Makefile.config. They just need a Makefile.common that all the sub
directories include and Makefile.common just needs to pick up llvm's
Makefile.config and Makefile.rules (via LLVM's Makefile.common).
The only reason we continue to have configured Makefile.config and
configure scripts is (a) because the project truly needs configurable
options or (b) that's just the way the project was before configuration
was made optional.
> 
> > 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.
Yes, I was thinking about doing the refactoring as a separate project
and then have LLVM use that project. The *only* issue with this approach
is that we might loose a modicum of control if many others used the
makefile system. However, that could also benefit us by getting
new/better features out of the makefile system. Anyway, this isn't a
decision we need to make right now. If I or someone else gets the
impetus to polish everything up, make it modular, document it properly,
etc. then so be it. This could be a natural result of projects like XPS
or other large LLVM based projects wanting to use a makefile system that
isn't necessarily tied to LLVM.  Anyway, lets cross that bridge when we
get there.

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/4127c341/attachment.sig>

On Mon, 14 Feb 2005, Reid Spencer wrote:
> isn't necessarily tied to LLVM.  Anyway, lets cross that bridge when we
> get there.
Sounds good.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/

> > > 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.
>
> Okay, I'll make that happen :)
>
> > >> 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.
>
> Right.
>
In current state removing this files break $(PROJ_SRC_ROOT)/configure run:
"configure: error: cannot find install-sh or install.sh in autoconf 
../src/autoconf"
> > >> 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! :)
>
> It already is optional. Projects don't even have to have a
> Makefile.config. They just need a Makefile.common that all the sub
> directories include and Makefile.common just needs to pick up llvm's
> Makefile.config and Makefile.rules (via LLVM's Makefile.common).
> The only reason we continue to have configured Makefile.config and
> configure scripts is (a) because the project truly needs configurable
> options or (b) that's just the way the project was before configuration
> was made optional.
Is then installing mklib, install-sh, mkinstalldirs at LLVM install is 
acceptable.

I attempt modify LLVM makefile system and let LLVM projects used installed 
version of LLVM.

My plan:
1) add support installed LLVM version in Makefile.rules
(last patch version in 
http://mail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003331.html
and some comments in 
http://mail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003323.html )

2) shrink of files in LLVM projects using LLVM_(SRC|OBJ)_ROOT paths to only 
really requared
(this patch)

3) install files with LLVM install:
$(LLVM_SRC_ROOT)/Makefile.rules
$(LLVM_SRC_ROOT)/Makefile.common
$(LLVM_OBJ_ROOT)/Makefile.config
$(LLVM_OBJ_ROOT)/mklib
and (if current patch isn't acceptable)
$(LLVM_SRC_ROOT)/authoconf/install-sh
$(LLVM_SRC_ROOT)/authoconf/mkinstalldirs

4)  copy $(LLVM_SRC_ROOT)/Makefile.rules to $(LLVM_OBJ_ROOT)/Makefile.rules 
at LLVM build
and set
LLVM_MAKE_ROOT to LLVM_ROOT or LLVM_OBJ_ROOT

5) add to llvm-java (and for consistency in Stacker and sample) configure.ac 
support --with-llvm option
as alternative to --with-llvmsrc/--with-llvmobj
and add to $(PROJ_SRC_ROOT)/Makefile.common.in code for seting LLVM_ROOT
and add to $(PROJ_SRC_ROOT) using LLVM_MAKE_ROOT instead LLVM_(SRC|OBJ)_ROOT 
paths.

At this point LLVM projects can build using installed LLVM version or only 
build LLVM version.

Vladimir