Skip to content

[make install] Shouldn't install utils, examples or projects/sample #1100

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
lattner opened this issue Apr 5, 2006 · 11 comments
Closed

[make install] Shouldn't install utils, examples or projects/sample #1100

lattner opened this issue Apr 5, 2006 · 11 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla enhancement Improving things as opposed to bug fixing, e.g. new or missing feature

Comments

@lattner
Copy link
Collaborator

lattner commented Apr 5, 2006

Bugzilla Link 728
Resolution FIXED
Resolved on Feb 22, 2010 12:54
Version 1.6
OS All

Extended Description

It would be nice if make install (or make install-something-else) only installed the LLVM libraries and
tools, not llvm/utils, llvm/examples and llvm/projects.

The utils is only used when building LLVM (not by clients who use the llvm headers/libraries), the others
are only used by developers not by people looking to link to llvm libraries and use tools.

-Chris

@lattner
Copy link
Collaborator Author

lattner commented Apr 5, 2006

assigned to @lattner

@llvmbot
Copy link
Member

llvmbot commented Apr 7, 2006

So, how about "make full-install" to get everything and default "make install"
to just tools/libs/headers/runtime ?

@lattner
Copy link
Collaborator Author

lattner commented Apr 7, 2006

For the record, "make full-install" and "make install" sound great :)

@llvmbot
Copy link
Member

llvmbot commented Apr 7, 2006

Okay, one question on this:

When you say you don't want the "utils" installed with "make install", then I'm
assuming that doesn't apply to things like burg, tblgen and fpcmp. Wouldn't a
developer need those if he's building a back end or running llvm-test?

@lattner
Copy link
Collaborator Author

lattner commented Apr 7, 2006

llvm-test isn't run with an installed tree, so that's not an issue (it uses fpcmp).
burg is SparcV9 only, so it's not either.

tblgen is used by targets outside the tree, if they could possible exist. I don't think it works and I'm
not aware of anyone doing this though.

At least at apple, people don't use 'make install'ed trees to do development of LLVM libraries (e.g. code
generators). Instead, they use 'make install'd trees when they want to consider a distro of LLVM as a
given that they link into their app, using the libraries. F.E. Morton with his JIT raytracer thing wants to
link the codegen and other libraries into his app, but isn't doing llvm development per-say with it. For
this sort of use, you definitely do not need tblgen.

Do you really see any reason people would be compelled to build a target out of tree? Building a target
still often requires extensions to the code generator libraries and other things, so I can't see this as
being something possible, even if the makefile machinery supported it.

-Chris

@llvmbot
Copy link
Member

llvmbot commented Apr 7, 2006

I'm not attached to the outcome. I was just asking a question. I had no idea how
these things are used. Now that you've explained, I understand. So, I will avoid
the utils directory for the install target. All you'll get are libs and tools.

@lattner
Copy link
Collaborator Author

lattner commented Apr 7, 2006

ok, sounds good. Don't forget includes :)

Thanks Reid!

-Chris

@llvmbot
Copy link
Member

llvmbot commented Apr 7, 2006

This is turning into quite a bit of work and so I'm going to combine it with
some work I've been doing on reorganizing the makefile system. The basic change
to the makefiles will be:

  1. putting all the Make.* files into a new llvm/make directory
  2. creating a Make.* file for each type of thing built. e.g. Make.lib, Make.tool
    each of which will be some dissection of the current Makefile.rules file.
  3. using the gmake "include" feature to specify the type of thing to be built
    rather than using lots of variables specify what should be done.

Consequently, this bug won't get resolved until (probably) after 1.7 is shipped.
The new makefile system (heavily influenced by current system) will appear in
LLVM 1.8.

@lattner
Copy link
Collaborator Author

lattner commented Apr 7, 2006

Sounds great. I like that design.

Thanks,

-Chris

@lattner
Copy link
Collaborator Author

lattner commented Apr 12, 2006

This isn't slated for 1.7

@lattner
Copy link
Collaborator Author

lattner commented Jun 3, 2006

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
@Endilll Endilll added enhancement Improving things as opposed to bug fixing, e.g. new or missing feature and removed missing-feature labels Aug 15, 2023
xlauko pushed a commit to trailofbits/instafix-llvm that referenced this issue Mar 28, 2025
This patch implements transformations for VAArg in X86_64 ABI **in
shape**. `In shape` means it can't work properly due to the dependent
X86_64 ABI is not robust. e.g., when we want to use VAArg with `long
double`, we need llvm/clangir#1087.

This patch literally implement
https://github.com/llvm/llvm-project/blob/d233fedfb0de882353c348cd1ac57dab619efa6d/clang/lib/CodeGen/Targets/X86.cpp#L3015-L3240
in CIR.

There some differences due to the traditional pipeline are converting
AST to LLVM and we're transforming CIR to CIR. And also to get the ABI
Info, I moved `X86_64ABIInfo` to the header.
jrbyrnes pushed a commit to jrbyrnes/llvm-project that referenced this issue Apr 29, 2025
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla enhancement Improving things as opposed to bug fixing, e.g. new or missing feature
Projects
None yet
Development

No branches or pull requests

3 participants