llvm dev - Feb 2005 - [LLVMdev] Add ability for external projects use for build installed version LLVM [PATCH]

>> Patch attached.
>>
>> This patch with header installation patch ( 
>> http://mail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003300.html )
>> let external project (I am test it at my YAFL frontend for LLVM) build 
>> using installed LLVM version instead using LLVM obj/src dirs.
>
> I think the patch looks basically sane.  The one wierd thing I notice is 
> the replacement of mklib with libtool.
Ops...  I must be more careful. Updated patch attached.

I use for build libtool "ltmain.sh (GNU libtool) 1.5.10" without
problems.
But I add code to preserve use $(LLVM_OBJ_ROOT)/mklib if LLVM_OBJ_ROOT set
In other cases if $(LLVM_OBJ_ROOT)/mklib using important it installation can 
be added to LLVM/PROJ install process
> However, this is definitely something Reid should review.  I think he's
> currently out of town but will be back next week.
Waiting... :)

Vladimir
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.rules.patch
Type: application/octet-stream
Size: 6229 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050209/2834c32a/attachment.obj>

Vladimir,

I took a *very quick* look at your patch. I won't be able to look at it in
more
detail until this weekend, but perhaps you can address a couple of concerns:

1. I don't understand the need for LLVMToolDirSlash. This seems like a
    gratuitous change to me.
2. I don't think the change to CPP.Flags is right. It won't find the
LLVM
    header files
3. Removing the .PRECIOUS line will interfere with correct operation of
    parallel (make -j N) builds.
4. I don't understand why LLVMUsedLibs and other variables should only be
    set if LLVMLibDir is defined.

Before this change is committed, you need to test that all our scenarios, in 
each combination:

1. Both with and without OBJ_DIR == SRC_DIR
2. Single and Parallel builds
3. Building LLVM versus building a project (and now building from installed)

Reid.

Vladimir Merzliakov wrote:
>>> Patch attached.
>>>
>>> This patch with header installation patch ( 
>>> http://mail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003300.html
)
>>> let external project (I am test it at my YAFL frontend for LLVM) 
>>> build using installed LLVM version instead using LLVM obj/src dirs.
>>
>>
>> I think the patch looks basically sane.  The one wierd thing I notice 
>> is the replacement of mklib with libtool.
> 
> Ops...  I must be more careful. Updated patch attached.
> 
> I use for build libtool "ltmain.sh (GNU libtool) 1.5.10" without
problems.
> But I add code to preserve use $(LLVM_OBJ_ROOT)/mklib if LLVM_OBJ_ROOT set
> In other cases if $(LLVM_OBJ_ROOT)/mklib using important it installation 
> can be added to LLVM/PROJ install process
> 
>> However, this is definitely something Reid should review.  I think 
>> he's currently out of town but will be back next week.
> 
> Waiting... :)
> 
> Vladimir
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev

> Vladimir,
>
> I took a *very quick* look at your patch. I won't be able to look at it
in
> more detail until this weekend, but perhaps you can address a couple of
> concerns:
>
> 1. I don't understand the need for LLVMToolDirSlash. This seems like a
>    gratuitous change to me.
If LLVM_OBJ_ROOT (with LLVM_SRC_ROOT) and LLVM_ROOT both not set
without LLVMToolDirSlash we will have "/gccas$(EXEEXT)", for example.
This is not problem for project that not use LLVM tools and libs.
But this not permite one useful case: project that use only LLVM tools and 
LLVM tools
directory added to PATH.
In this case using LLVMToolDirSlash we have correct tool name
"gccas$(EXEEXT)" and tool can find by PATHs.
> 2. I don't think the change to CPP.Flags is right. It won't find
the LLVM
>    header files
I build my frontend in LLVM_ROOT set case and LLVM headers find fine.

I already found bug in LLVM_OBJ_ROOT case in proposed patch :(
+  LLVMIncDirs := $(LLVM_OBJ_ROOT)/$(BuildMode)/include
instead

+  LLVMIncDirs := $(LLVM_OBJ_ROOT)/include
> 3. Removing the .PRECIOUS line will interfere with correct operation of
>    parallel (make -j N) builds.
When external project build
$(LLVMLibDir)/.dir $(LLVMToolDir)/.dir $(LLVMExmplDir)/.dir files and
directories already exist and then
using .PRECIOUS redundent in this case (as i think).
In time LLVM build this files and directories listed in line:
.PRECIOUS: $(ObjDir)/.dir $(LibDir)/.dir $(ToolDir)/.dir $(ExmplDir)/.dir
I will test patch with parallel builds.

Related question lines:
-LLVMExmplDir:= $(LLVM_OBJ_ROOT)/$(BuildMode)/examples
and
-.PRECIOUS: $(LLVMLibDir)/.dir $(LLVMToolDir)/.dir $(LLVMExmplDir)/.dir

Is removing LLVMExmplDir definition is ok? It not used anywhere in LLVM CVS
> 4. I don't understand why LLVMUsedLibs and other variables should only
be
>    set if LLVMLibDir is defined.
I don link strange filenames if LLVMLibDir will not define and  project
tooldir/Makefile set LLVMLIBS.
But i will skip this part of changes in next version of patch.
> Before this change is committed, you need to test that all our scenarios,
> in each combination:
>
> 1. Both with and without OBJ_DIR == SRC_DIR
> 2. Single and Parallel builds
> 3. Building LLVM versus building a project (and now building from
> installed)
ok, will do...

I found some bugs in my patch and then I will send updated version after it 
testing.

Thank you for comments!

Vladimir