[lldb-dev] Compiling LLDB on Linux, certain types don't exist at all?

[Stephen Wilson]

Hi Austin,

austin seipp <as at hacks.yi.org> writes:

> Stephen,
>
> Thank you for the follow-up, I figured I was not the only person
> interested in this. re: the build issue, I assume the Makefiles on
> linux just blindly compile all *.cpp files in the current directory,
> whereas xcode project configurations will explicitly enumerate the
> files that need to be built, so unused files are not a problem. I
> assume nobody has used the makefiles for quite some time, so they've
> fallen out of date (indeed, the commit logs say they have not been
> touched for a while.)
>
> Hopefully your changes can get merged soon. If you publish your git
> repository before then (or after, if you plan on continuing working on
> linux support,) please be sure to follow up with a URL so we could
> collaborate in the future if you don't mind. I'd like to see LLDB on
> Linux as I have gradually been moving all my personal code and
> machines to Clang, and I do most of my development on Linux, not on OS
> X. Once your changes are merged, more interesting things can be worked
> on (and hopefully kept in sync with the tree.)

I pushed the current state of my tree onto the lldb-linux branch here:

   https://github.com/eightcien/lldb/tree/lldb-linux


I have not thoroughly reviewed all of the changes myself -- but the tree
does build.  Will be picking the critical commits out and sending them
to the list for review over the next few days (I hope).

I probably will not be looking at adding any features to the linux side
of things for a while -- just concentrate on getting the build working
and cleaning up as many compilation warnings as I can.  Will keep the
github tree up to date as I work.

Take care,

>> If you use master to track the svn repo I would recommend that you do
>> not rebase your "linux" branch -- just update master using 'git svn
>> rebase' which should always be a simple fast-forward and pull those
>> changes into the "linux" branch using a merge commit.  That way you have
>> a proper history that others using git can pull from while staying up to
>> date.  Of course, you would need to manage any merge-conflicts, etc.
>
> This sounds like a much better idea and I can't believe I hadn't
> thought of it, thanks.
>
> Regards,
> Austin

--
steve