Skip to content
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.

Sign up for GitHub

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

Jump to bottom

move test/Programs out of the main llvm tree #629

Closed
llvmbot opened this issue Feb 26, 2004 · 12 comments
Closed

move test/Programs out of the main llvm tree #629

llvmbot opened this issue Feb 26, 2004 · 12 comments

Comments

@llvmbot
Copy link
Member

llvmbot commented Feb 26, 2004

Bugzilla Link 257
Resolution FIXED
Resolved on Feb 22, 2010 12:56
Version trunk
OS All
Depends On #613
Blocks #628
Reporter LLVM Bugzilla Contributor
CC @lattner

Extended Description

This will allow us to simplify the machinery for running the tests under
test/Programs and also make build changes to the rest of the tree much more
easily.

The Programs subdirectory should be a different module in cvs which once
dropped in under $srcdir/test, be picked up by configure, configured and
integrated in the build process as it is today (in other words once it is
checked out in the right place, running it should not be different than what
it is today).
@lattner
Copy link
Collaborator

lattner commented Feb 26, 2004

I mentioned this to brian, and he pointed out that test/Regression/CFrontend and
other tests that depend on the C front-end should be moved as well...

-Chris

@lattner
Copy link
Collaborator

lattner commented Feb 26, 2004

Changing all of these bugs who do not have people looking at them to be assigned
to "unassignedbugs", indicating that if someone is feeling ambitious, they can
take ownership of the bug.

If I stole your bug, and you still want it, feel free to take ownership back.

-Chris

3 similar comments
@lattner
Copy link
Collaborator

lattner commented Feb 26, 2004

Changing all of these bugs who do not have people looking at them to be assigned
to "unassignedbugs", indicating that if someone is feeling ambitious, they can
take ownership of the bug.

If I stole your bug, and you still want it, feel free to take ownership back.

-Chris

@lattner
Copy link
Collaborator

lattner commented Feb 26, 2004

Changing all of these bugs who do not have people looking at them to be assigned
to "unassignedbugs", indicating that if someone is feeling ambitious, they can
take ownership of the bug.

If I stole your bug, and you still want it, feel free to take ownership back.

-Chris

@lattner
Copy link
Collaborator

lattner commented Feb 26, 2004

Changing all of these bugs who do not have people looking at them to be assigned
to "unassignedbugs", indicating that if someone is feeling ambitious, they can
take ownership of the bug.

If I stole your bug, and you still want it, feel free to take ownership back.

-Chris

@lattner
Copy link
Collaborator

lattner commented Apr 14, 2004

Here's something that I sent to John just today:

In theory, it sounds like we want
a directory layout like this:

llvm/
lib/...
include/...
test/
Feature/
Regression/...
...
projects/
c-frontend/
gcc/...
test/
C++Regression/...
CRegression/...
runtime/
crtend/
Stacker/...
Libraries/
libz/
libpng/
libc/
...
TestPrograms/
MultiSource/...
SingleSource/...
External/...

The idea being that everything under projects is optional. We could
rename "projects" to "modules", and be set. I think that this would
achieve what we want (make test/Programs optional, pull stuff out of the
main CVS tree, simplify dependencies, etc).

What do you think?

-Chris

@llvmbot
Copy link
Member Author

llvmbot commented Apr 14, 2004

The basic idea looks good, with one minor tweak that I would like to suggest.

One of the ideas behind CVS is the notion of "modules" which tyipcally
correspond to the top level directory names (although they don't have to). We
currently have one "llvm" module with everything under it. While stating that
"projects" is optional, it will still be checked out when someone does:

cvs -d :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm checkout .

I think the repository should be made a little flatter, structured this way:

/var/cvs/llvm/llvm - Everything you have under /llvm
/var/cvs/llvm/c-frontend - Everything you have under /llvm/Projects/c-frontend
/var/cvs/llvm/projects - Stacker, examples, etc.
/var/cvs/llvm/test - What you have under /llvm/Projects/TestPrograms

This way, one can set CVSROOT to .../var/cvs/llvm
and get everything with: cvs -d .../var/cvs/llvm co .
or get just the core with: cvs -d .../var/cvs/llvm co llvm
or get just the test suite wth: cvs -d ../var/cvs/llvm co test
or get just the projects with: cvs -d ../var/cvs/llvm co projects

I believe this arrangement works for everyone. Developers of LLVM can just use
"cvs ... co ." which garners them everything. Users of LLVM can select which
piece they want with the appropriate co shown above.

Also with this arrangement you can go to the top of your checkout directory and
just "cvs update" to update individual portions. With the structure you
suggested, if I went to /llvm and did "cvs update", I would end up updating all
the projects and TestPrograms as well as the core and the c-frontend. This isn't
what I want most of the time. Generally, I just want the core. Occassionally I
want stacker. I never want the test programs (other than the regressions in the
core), and I'm afraid of the c-frontend :) The alternative right now is to
visit all the top level directories under llvm
(lib,include,docs,autoconf,runtime,tools) and cvs update each of them. Yuck! :)

Reid.

@lattner
Copy link
Collaborator

lattner commented Apr 14, 2004

Oh yeah, I forgot to mention, that this was similar to the plan. We already do
exactly this with the projects system, which is why I put all of the optional
stuff in the project subdir. For example, we have an 'internal cvs' repo that
has things like the pool allocator, reoptimizer, and other misc stuff in it. To
work on the pool allocator, I just check out that module under the projects
directory. Since CVS is recursive, it automatically goes into that directory
and doesn't even notice that it's in a different repo. :)

When packaging the release, the different CVS modules would go into different
tarballs/rpms/debs/whatever, and the default checkout would JUST give you LLVM.
To get the testsuite, you would have to check out its module as well.

-Chris

@llvmbot
Copy link
Member Author

llvmbot commented Aug 5, 2004

The --enable-jit and --enable-llc_diffs options should move from the main configure
script to the test/Programs configure script, as well.

@llvmbot
Copy link
Member Author

llvmbot commented Sep 5, 2004

The conversion has been completed. John C did the basic work of creating a new
cvs module (llvm-test) that contained the test scripts and basic autoconf
support. I polished that up and made it at least work for the nightly tester.
There may be a few other glitches that I haven't found yet, but the build of the
work is done and it works.

SOOOO .. here's what you need to know:

  1. llvm/test/Programs is now "empty"

  2. llvm/test/Regression and llvm/test/Feature remain, unchanged

  3. to build the test suite you need to:
    cd $LLVM_SRC_ROOT/projects
    cvs co -PR llvm-test
    cd $LLVM_OBJ_ROOT/projects
    $LLVM_SRC_ROOT/configure --with-llvmsrc=$LLVM_SRC_ROOT
    --with-llvmobj=$LLVM_OBJ_ROOT
    gmake

  4. The llvm configure script will invoke the projects/llvm-test configure
    script properly if you'd rather do that.

  5. In 1.4 the source tarball for llvm won't contain the Programs test suite
    which should make it significantly smaller.

  6. The NightlyTest.pl script has been modified to take the above into account.

Happy Testing.

@llvmbot
Copy link
Member Author

llvmbot commented Sep 5, 2004

Reopen to assign.

@llvmbot
Copy link
Member Author

llvmbot commented Sep 5, 2004

Re-resolve after assignment.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 1, 2021
pysuxing pushed a commit to pysuxing/llvm-project that referenced this issue Jul 17, 2024
@sitio-couto
[CIR][IR][NFC] Fix CallOp builder with void return (llvm#629)

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode
492242b 
One of the builders was adding a retun value to the CallOp when given a
void return type. The expected behavior is to not add a return value.
Two other minor fixes were added to the return value: its constraint was
replaced from variadic to optional and it was assigned a name. This
prevents function calls with multiple returns and facilitates access to
the single return value, respectively.
pysuxing pushed a commit to pysuxing/llvm-project that referenced this issue Jul 17, 2024
@sitio-couto @lanza
[CIR][IR][NFC] Fix CallOp builder with void return (llvm#629)
db2fa4a 
One of the builders was adding a retun value to the CallOp when given a
void return type. The expected behavior is to not add a return value.
Two other minor fixes were added to the return value: its constraint was
replaced from variadic to optional and it was assigned a name. This
prevents function calls with multiple returns and facilitates access to
the single return value, respectively.
keryell pushed a commit to keryell/llvm-project that referenced this issue Oct 19, 2024
@sitio-couto @lanza
[CIR][IR][NFC] Fix CallOp builder with void return (llvm#629)
ee8a3b3 
One of the builders was adding a retun value to the CallOp when given a
void return type. The expected behavior is to not add a return value.
Two other minor fixes were added to the return value: its constraint was
replaced from variadic to optional and it was assigned a name. This
prevents function calls with multiple returns and facilitates access to
the single return value, respectively.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@lattner @llvmbot