install-bytecode no longer works

My rebuild from scratch has hit this snag. The instructions still call
for running "gmake -C runtime install-bytecode", but this target no longer exists.

Yeah, its just "install" now.

I'll fix the documentation.

Reid.

But there already was an "install", and it did far more than install the
bytecode files. That changed too?

The entire makefile system was rewritten a couple of weeks ago. This is
a good thing, your compiles now go twice as fast. Resistance is futile,
just adapt :slight_smile:

The install target installed the bytecode libs into CFEINSTALL as before
and also installs the native libraries to your prefix/lib directory.
This is intentional.

Reid

Wow... it is nearly twice as fast. But it tried to install stuff in
/usr/local (and as I wasn't root...) and it didn't do that before. As I
don't care about profiling or tracing, I didn't bother to su and do it
again.

The default prefix is /usr/local but I would recommend that when you
configure LLVm you do so with:

configure --prefix=/me/llvm/install/dir ...

so that installation occurs in a place you have write access. If you
feel strongly about restoring the install-bytecode target, feel free to
file a bug.

Reid.

No, I don't feel strongly about it... it's just annoying to have things
change on me that break habits :slight_smile:

On the other hand, I do feel strongly about the tests in llvm-test that
are now failing on me because they explicitly include alloca.h, a file
that does not exist on FreeBSD. I can supply a patch to take out the
include, of course, but the problem then becomes that the tests will
then fail on other Unix platforms. Some way is needed to make the tests
platform-independent. As a workaround for now I guess I can add an
empty alloca.h file.

This kind of thing is one of the many reasons we broke llvm-test out to
a separate project. It has multiple purposes. Its a correctness test on
LLVM, its what we base our compiler benchmarks on, and its also where a
lot of the research gets done. You've been bitten by the latt(n)er. :slight_smile:

At some point I'd like to see us make some distinctions so that there is
a correctness test suite whose goal is to always work on all platforms.
To date the llvm/test/{Regression,Feature} provide that capability in a
very minimal way.

You're probably best to just define alloca as malloc in alloca.h and
just hope it doesn't break semantics.

Reid.

Oh, I don't have to change any semantics... FreeBSD has alloca(); it's
just not declared in alloca.h. It's declared in stdlib.h. I have to
admit I don't understand why alloca has to be declared in different
fashions on different flavors of Unix even though they use the exact
same gcc. Anyway, the hack appears to be working...

I haven't run llvm/test yet... I want to try dejagnu and I haven't
gotten around to setting it up yet.

On the other hand, I do feel strongly about the tests in llvm-test that
are now failing on me because they explicitly include alloca.h, a file
that does not exist on FreeBSD. I can supply a patch to take out the
include, of course, but the problem then becomes that the tests will
then fail on other Unix platforms. Some way is needed to make the tests
platform-independent. As a workaround for now I guess I can add an
empty alloca.h file.

The test could always be marked XFAIL for FreeBSD. This can easily be done
with the dejagnu support. Other ideas are that certain directories in the
test suite could only be run on certain platforms (also easily done with
dejagnu).

-Tanya

This kind of thing is one of the many reasons we broke llvm-test out to
a separate project. It has multiple purposes. Its a correctness test on
LLVM, its what we base our compiler benchmarks on, and its also where a
lot of the research gets done. You've been bitten by the latt(n)er. :slight_smile:

At some point I'd like to see us make some distinctions so that there is
a correctness test suite whose goal is to always work on all platforms.
To date the llvm/test/{Regression,Feature} provide that capability in a
very minimal way.

llvm-test has many purposes, but it's is there foremost as end-to-end
tests for LLVM. The best way to do this, IMO is to take random programs
off the shelf and plunk them in there.

The problem with this, of course, is that these programs are often crufty,
maybe buggy, and often have portability problems.

I don't really see a solution to this: if we only accepted non-crufty,
non-buggy, portable programs, we would have an empty set of tests :slight_smile:

The solution to this is just to hack on the programs where necessary.
I've fixed countless bugs in the programs in llvm-test and portability is
no different. As long as the spirit of the program stays alive (i.e. no
functionality changes) that is no problem.

Perhaps the right way to handle this particular problem is to add the
appropriate autoconf check to the llvm-test configure, then have the
programs that need alloca use the detected value?

-Chris

Its already in the llvm configure which is inherited by llvm-test. If
you want to define this in the makefiles, add the following to
llvm-test/Makefile.config.in:

HAVE_ALLOCA_H = @HAVE_ALLOCA_H@

Reid.

Maybe the llvm-test module should have a config.h file? Or perhaps
llvm-test should use the main llvm compatibility headers? We've already
solved *this* issue with include/llvm/Config/alloca.h right?

-Chris

Maybe the llvm-test module should have a config.h file?

perhaps, but that means modifying all the programs to use it as well and
a lot of them have their own config.h because they are supposed to be
configured as well.

Or perhaps
llvm-test should use the main llvm compatibility headers?

perhaps, but again that requires the test programs to be modified.

We've already
solved *this* issue with include/llvm/Config/alloca.h right?

yes, a month or so ago.

Reid.

> Maybe the llvm-test module should have a config.h file?

perhaps, but that means modifying all the programs to use it as well and
a lot of them have their own config.h because they are supposed to be
configured as well.

We wouldn't need to have a configure script for each program, just union
all of the checks into the top level llvm-test configure.

> Or perhaps
> llvm-test should use the main llvm compatibility headers?

perhaps, but again that requires the test programs to be modified.

That is not a problem.

-Chris