Getting Started

I know this process is well documented here http://llvm.org/docs/GettingStarted.html

But man do I love scripting things:

LLVM Getting Started (See http://llvm.org/docs/GettingStarted.html)
./getttingStarted.sh [-clang] [-compiler-rt] [-test-suite] [-branch branch]
[-dir path] [-r rev]

By default this script checks out ToT LLVM to the current working directory

Project Options:
-clang Checkout Clang repo
-compiler-rt Checkout Compiler RT
-test-suite Checkout LLVM test-suite

Configuration Options:
-branch branch Checkout a specific branch, default trunk
-dir path Checkout to path instead of current working dir
-r rev Checkout to a specific revision
-v Verbose mode

-help Print this message

The shell script is attached, if you are interested. Perhaps we can add this to the GettingStarted doc?

Joe

gettingStarted.sh (3.84 KB)

ATT00001.htm (238 Bytes)

I think this is a good idea, although personally I'd prefer the script
to be written in Python to allow more portability (i.e. using it on
Windows as well).

Eli

Agreed.

I thought about that right after I clicked send... should have come up during prototyping.

I'll scrub and repost.

Joe

Hithere.

If you used a makefile then theoptions could be makefile variables.
You could then also build what you downloaded/updated.
Then you could also specify -j7 and the parallel build options would be
passed to llvm's make process.
Lastly you could add targets to make a debian package and/or the
documentation.

Just my 2c.

Regards,
Philip Ashmore

This is very cool. Thanks for doing this!

-Jim

I'd like to throw in a suggestion for Perl instead. I have 4 different versions of Python installed on my Windows machine at home right now and have to figure out which one actually works and manually specify it for any given build system / program / etc which needs it. Meanwhile, the single Perl install just works for everything.

Just my experience there...

-Gordon

I'd like to throw in a suggestion for Perl instead. I have 4 different versions of Python installed on my Windows machine at home right now and have to figure out which one actually works and manually specify it for any given build system / program / etc which needs it. Meanwhile, the single Perl install just works for everything.

So it should be written in Perl because you have a lot of Python
versions installed on your home machine and can't sort them out to run
the correct version for things you need?

Eli

They're all sorted out at this point. I'd just rather not end up with another one.
Just ignore my post, I
  a) Don't want to start a scripting language debate
  b) Will just use SVN commands instead

-Gordon

I've never written python... but here goes.

Attached.

Joe

gettingStarted.py (3.81 KB)

I think this is a good idea, although personally I'd prefer the script
to be written in Python to allow more portability (i.e. using it on
Windows as well).

I've never written python... but here goes.

Joe, thanks for the effort. Could you re-post it as a PATCH post to
llvm-commits?

Eli

I've never written python... but here goes.

This is an awesome idea! I have a shell script for the same purpose,
but I didn't post it because it was not as 'user-friendly'. (And I
suspect lots of other developers have similar scripts.)

   print (msg)

print does not need parentheses.

curdir=os.getcwd();
project=target;

Semicolon is not needed.

os.chdir(orig_dir) #Go back

No need in that, current directory is per-process.

There are other style issues, I hope
<http://www.python.org/dev/peps/pep-0008/> would be helpful.

Dmitri

Hello,

> I've never written python... but here goes.

This is an awesome idea! I have a shell script for the same purpose,
but I didn't post it because it was not as 'user-friendly'. (And I
suspect lots of other developers have similar scripts.)

> print (msg)

print does not need parentheses.

Only up to Python 2.7.
As far as I checked, if all prints get parantheses the script is compatible
with all Python versions since Python 2.5.

[...]

Dmitri

Christoph

So instead of being able to quickly extend scripting via Bash or C Shell you’d prefer people learn Python to extend any functionality?

Cygwin is well tested on Windows. Shell Scripting [Bash, C, Ksh, ZShell, etc] is pervasive in UNIX/Linux and won’t be replaced by Python or Perl.

Simple automated scripts requiring the memory footprint of python just to make it work in Windows seems counter-intuitive to the fact that LLVM/Clang is primarily UNIX first.

  • Marc

P.S. Please let’s not have a discussion of install size of components. It’s 2012, not 1996. That argument went out the window when we went from 30GB drives to 4 TB drives.

If you are doing a build using the UNIX-like way of checking everything out and building it, then you will already have a shell installed via mingw or cygwin on Windows. If you are doing a build via Visual Studio or similar, then you will not be using this script. Rewriting it in Python just adds a needless dependency.

David

David Chisnall <David.Chisnall@cl.cam.ac.uk> writes:

I think this is a good idea, although personally I'd prefer the script
to be written in Python to allow more portability (i.e. using it on
Windows as well).

If you are doing a build using the UNIX-like way of checking
everything out and building it, then you will already have a shell
installed via mingw or cygwin on Windows. If you are doing a build via
Visual Studio or similar, then you will not be using this script.

There is no "Unix-like way of checking everything out". The method is
exactly the same on MS-Windows and Unix. The script does not build, but
even doing that step requires the same commands for Visual Studio and
GCC (at least if you use CMake, because the configure&make build is
useless for VS.)

Rewriting it in Python just adds a needless dependency.

"needless" as "I don't care about what it adds"? :wink:

IMHO, this script adds very little convenience. Maybe it saves you one
minute or two the first time you checkout the working copies and it is
oblivious to some popular variants (git mirror, for instance.) But if
anyone finds it useful, good for him.

Hi Joe, thanks for working on this.

My honest opinion on it is that time would be better spent improving
the documentation, as the current documentation is archaic. I think
this has come up on the list before, but to rehash:

* Start out by saying "LLVM can be built with make or CMake, and
checked out with svn or git", and have "make", "CMake", "svn", and
"git" be links to their own section talking about the relevant thing.

* Treat the different options on equal footing. The current document
is extremely SVN/make centric.

Overall, I think that adding automation to this is not really going to
help that much for a newcomer (especially considering the portability
concerns cited by others). TBH, it's not that difficult to set up.
What *is* difficult is wading through the current documentation to
find out that "oh hey, they support git", or "oh, they have CMake so I
can develop in visual studio like I'm comfortable with".

Also, as I'm sure you have witnessed on the lists, choice of build
system and (local) version control is something that people are quite
vehement about, to the point that failing to put those options in
newcomers' faces could result in outright *losing a developer* or at
least dampening their enthusiasm (the importance of which is not to be
underestimated). I have yet to see anyone complain about a lack of
automation for getting set up.

-- Sean Silva

+1.

That's cool. It was a nice exercise to learn python, and gain a better understanding of how reST works. Thanks Eli and Dmitri!!

While the script is super useful for my workflow, it is a solution to a problem that may not even exist. Since the script is out there in a few patch incarnations, I suspect that's where we should leave it. I'm not going to push to get it in, especially if I'm the only beneficiary. :slight_smile:

I'm a proponent of modernizing the getting started documentation. I'm happy to help with the svn and cmake parts as that's what I tend to focus on.

Cheers,

Joe

Sorry to chime in, this is just killing me.

First off thanks for the effort in thinking about the issue and providing a convenient solution for beginners.

Here is the killer for the LLVM mailing list to argue for or against bash, python Perl, etc c'mon, lets add ruby, Lua and NodeJS.
I completely agree with the notion that it is cool to learn a new scripting language what is more important is consistency. If I have to install all of the above it is an issue. If the project stays with E.g. bash or Python it does not matter. Any decent OS will support it unless you want to do this in an embedded environment.

I personally would love to see this done through C++ scriptlets. I love, love, love cling !!! Before cling I was dearly in love with CINT. But hey, that's just me :slight_smile:

Thanks again for this initiative. I think it is a good thing to give some one who wants to start out.

Varol