×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

LLVM and Clang 3.4 Are Out

Unknown Lamer posted about a year ago | from the features-are-nice dept.

Programming 118

An anonymous reader writes that the LLVM compiler framework and Clang C++ compiler hit 3.4 "With C++14 draft fully implemented in Clang and libc++. Read more in LLVM and Clang release notes." Also of note: "This is expected to be the last release of LLVM which compiles using a C++98 toolchain. We expect to start using some C++11 features in LLVM and other sub-projects starting after this release. That said, we are committed to supporting a reasonable set of modern C++ toolchains as the host compiler on all of the platforms. This will at least include Visual Studio 2012 on Windows, and Clang 3.1 or GCC 4.7.x on Mac and Linux. The final set of compilers (and the C++11 features they support) is not set in stone, but we wanted users of LLVM to have a heads up that the next release will involve a substantial change in the host toolchain requirements."

Sorry! There are no comments related to the filter you selected.

pretty quick on the C++14 support (3, Interesting)

Trepidity (597) | about a year ago | (#45888863)

Does that make it the first compiler with full draft C++14 support? GCC is making progress [gnu.org] but not there yet.

Re:pretty quick on the C++14 support (-1, Flamebait)

Anonymous Coward | about a year ago | (#45888913)

It's at least the leader. Yet another good readon for everyone to drop GCC and move on to the future. GCC is obsolete in pretty much every aspect, and the non-permissive license makes it hard to use for other purposes than simple command-line compilation compared to LLVM which can be integrated in many different products.

Re:pretty quick on the C++14 support (3, Insightful)

Trepidity (597) | about a year ago | (#45888987)

From a technical perspective I like LLVM, but I don't get the appeal of your 2nd point. Why should I work for free on a project in order to enable companies to make proprietary extensions to it that they won't release back to the community? The GPL makes me more willing to contribute to projects, because it ensures that everyone plays fair, so to speak: I'm adding my contributions, and if you find the results valuable and extend my work, you should do likewise.

Re:pretty quick on the C++14 support (4, Insightful)

Anonymous Coward | about a year ago | (#45889065)

The BSD folks tend to argue that things work out in the end anyway. Useful contributions find their way back, and when they don't then at least someone got some good code out of it. There are few exceptions, in general you can't force anyone to contribute back. Very few projects are that good. The only thing you achieve is that your code is used in less places.

Re:pretty quick on the C++14 support (4, Insightful)

HeckRuler (1369601) | about a year ago | (#45890871)

Ah yes, all those people running BSD... All those people.
Which, hey, if you include Apples OSX, is a hell of a lot of people. So yes, let us bask in all that effort that Apple has done for the open source community.

Very few [open/free] projects are that good.

Well with that sort of QUANTITY, you can't expect them all to be stellar.

The only thing you achieve is that your code is used in less places.

But those are places that you can actually use rather than the proprietary walled garden constrictive license which make for the sort of thing where you don't actually own the things you own. It also makes for a platform which is dead in the water and has no legs. And it's usually expensive.

I don't care if a few businessmen shy away from the code I throw out there under an free license. They most certainly wouldn't have helped me.

Re: pretty quick on the C++14 support (3, Insightful)

Bill_the_Engineer (772575) | about a year ago | (#45891315)

The problem with your argument being that Apple sponsors the clang and llvm project. I'm sure they put in more money than you, and we still enjoy the use of the BSD code.

Re: pretty quick on the C++14 support (1, Troll)

turgid (580780) | about a year ago | (#45892275)

The problem with your argument being that Apple sponsors the clang and llvm project. I'm sure they put in more money than you, and we still enjoy the use of the BSD code.

And one day they will put in proprietary extensions that only they can use, or maybe important customers, for a "reasonable" fee.

It wouldn't take much, but they could make a special Apple dialect of some important language. OK, someone may be free to implement their own compiler for that language, but that's not trivial.

Nope, I won't drink the BSD kool aid at the expense of the Free stuff. I remember the pre-GNU days.

Re: pretty quick on the C++14 support (1)

Bill_the_Engineer (772575) | about a year ago | (#45892345)

So you're not upset that the current codebase will remain available as BSD. You just want everyone to be forced to make available all of their extensions or software that may use some portion of the code.

Re: pretty quick on the C++14 support (1)

jeremyp (130771) | about a year ago | (#45896645)

And CUPS and Webkit.

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45891359)

So, basically you're putting restrictions on your code. Sounds like you have your own walled garden, sort of. =)

Re:pretty quick on the C++14 support (1)

Anonymous Coward | about a year ago | (#45892265)

Ah yes, all those people running BSD... All those people.

And NetApp, and Juniper, and EMC/Isilon, and Spectra Logic, and Sandvine, and Netflix.

You should check out the commit logs sometime where they have "Sponsored by".

Which, hey, if you include Apples OSX, is a hell of a lot of people. So yes, let us bask in all that effort that Apple has done for the open source community.

You mean like LLVM/Clang itself? The creator and lead developer of LLVM works for Apple. They also hired the CUPS guy, and sponsored FreeBSD security work.

Re:pretty quick on the C++14 support (1)

Goaway (82658) | about a year ago | (#45893373)

So yes, let us bask in all that effort that Apple has done for the open source community.

Like... clang?

Re:pretty quick on the C++14 support (4, Interesting)

jandrese (485) | about a year ago | (#45889087)

He's referring to integrating the compiler into your IDE. GCC makes this intentionally difficult, which is a big reason why there is no Visual Studio equivalent system that uses GCC. CLANG/LLVM is designed much more openly and should allow developers to really reach (and exceed) feature parity with Visual Studio.

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45889481)

GCC makes this intentionally difficult, which is a big reason why there is no Visual Studio equivalent system that uses GCC.

Where's the Visual Studio equivalent system that uses a BSD-licensed compiler?

Re:pretty quick on the C++14 support (2)

Anonymous Coward | about a year ago | (#45889541)

XCode?

Re:*BSD is DOA (0)

Anonymous Coward | about a year ago | (#45889825)

Buy a Mac and use XCode!

Re:pretty quick on the C++14 support (2)

postmortem (906676) | about a year ago | (#45889735)

Huh? QCreator, Netbeans and Eclipse C/C++ IDEs are fully integrated with GCC, including both debugging and compilation.

Re:pretty quick on the C++14 support (-1)

Anonymous Coward | about a year ago | (#45889827)

Fully integrated, or just "we called the compiler binary and parsed the output?"

Re:pretty quick on the C++14 support (4, Informative)

jandrese (485) | about a year ago | (#45889851)

What they can't do is micro-compile snippets of code to find errors, do auto-completion, etc...

I'll let the clang guys [llvm.org] explain it better.

Re:pretty quick on the C++14 support (5, Informative)

am 2k (217885) | about a year ago | (#45890273)

Huh? QCreator, Netbeans and Eclipse C/C++ IDEs are fully integrated with GCC, including both debugging and compilation.

What Xcode can do is integrate llvm with autocompletion. For example, if you do a switch statement on an enum-value, it autocompletes the possible enum constants after you type "case". After the first entry, it automatically removes the constants you already used from the list of possibilities.

Xcode also does perfect autocompletion (method names, parameter types, etc.) of types derived from C++ templates, which simply isn't possible without compiling the file. This even works as you change the same file those templates are declared in.

Other things include the analyzer, which tells you about issues that arise on certain input conditions. When you click on an issue, Xcode visually displays the flow through the program to arrive at the undesired end result using arrows.

Re:pretty quick on the C++14 support (0)

c++0xFF (1758032) | about a year ago | (#45890693)

They're not "fully integrated." IDEs can only call the gcc command, and have no access to internal data structures. The GPL prevents these IDEs from using the libraries directly.

Compare this to clang which provides a library API and has the license (BSD-like) to back this up.

Re:pretty quick on the C++14 support (3, Informative)

peppepz (1311345) | about a year ago | (#45891501)

Please update your FUD. GCC has supported a plugin architecture since 2010. You can use any GPL-compatible license for your plugin. This includes BSD, and in fact, there's a LLVM plugin for gcc [llvm.org] .

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45893465)

They're not "fully integrated." IDEs can only call the gcc command, and have no access to internal data structures. The GPL prevents these IDEs from using the libraries directly.

Compare this to clang which provides a library API and has the license (BSD-like) to back this up.

Wrong. An IDE can access all of gcc's internal structures - if the IDE itself is GPL licenced. So, no problem at all . . .

Re:pretty quick on the C++14 support (-1)

Anonymous Coward | about a year ago | (#45892083)

Netbeans and Eclipse suck balls, so they don't count.

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45890437)

And to elaborate on that point, companies with real resources to devote to improving the compiler are motivated to do so, because they are using it as the core in a larger toolchain.

Just because those companies may not open-source 100% of their work, doesn't mean there is zero benefit to the community.

Re:pretty quick on the C++14 support (2, Insightful)

Anonymous Coward | about a year ago | (#45889225)

Why should I work for free on a project in order to enable companies to make proprietary extensions to it that they won't release back to the community?

You shouldn't, but you should also not see it as a deterrent. Those companies will never release anything back to the community regardless of license.
Yes, while unlikely they might be able to make some more profit thanks to whatever you contribute but that is irrelevant since it doesn't actually harm you or the project.
On the other hand the way they think is that their source code is the most important thing they have and they will never make it public. Those companies will rather try to roll their own compiler than contribute to an open source project. By using a more permissive license you do not get more contributors in the form of programmers but I highly doubt that you get less either. What you do get is more contributors in the form of debugging and bug reporting.

Re:pretty quick on the C++14 support (1)

gbjbaanb (229885) | about a year ago | (#45889361)

actually, I'd say you would get more contributors - if the company you work for uses a permissive open-source project, some people will learn all about it at work, and will then scratch whatever itches they have with it at home, and release that code back to the community.

Re:pretty quick on the C++14 support (1)

serviscope_minor (664417) | about a year ago | (#45889547)

That works for GPL as well. Linux, GCC etc receive many (most?) contributions from companies.

Re:pretty quick on the C++14 support (1)

gbjbaanb (229885) | about a year ago | (#45889959)

the point was that BSD licences aren't some sort of black hole into which companies will take and give nothing. Even if a company does do that, it doesn't mean that the project won't gain from it regardless.

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45891147)

How many people will know that the commercial project X contains code from the BSD-licensed project Y? Especially if they have never heard about Y before.

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45891311)

Everyone who reads the required notice in project X, at least.

Re:pretty quick on the C++14 support (2)

angel'o'sphere (80593) | about a year ago | (#45889675)

Most people who program the whole day rather have a beer at home ...

Re:pretty quick on the C++14 support (1)

Anonymous Coward | about a year ago | (#45889651)

You would do this because then those companies will contribute back to you. You wouldn't have clang at all if Apple hadn't written pretty much all of it. Apple wrote pretty much all of it exactly because the GPL stopped them wanting to contribute to gcc.

Re:pretty quick on the C++14 support (2)

kthreadd (1558445) | about a year ago | (#45889903)

I'm sure it was Apple that stopped Apple from contributing to GCC. I'm thankful that they contributed to LLVM by developing Clang, but it was entirely their own choice to not contribute to GCC after 4.2.1.

Re:pretty quick on the C++14 support (3, Informative)

gnasher719 (869701) | about a year ago | (#45890015)

I'm sure it was Apple that stopped Apple from contributing to GCC. I'm thankful that they contributed to LLVM by developing Clang, but it was entirely their own choice to not contribute to GCC after 4.2.1.

It was an intentional change in the license that made it impossible for Apple to do some of the things they wanted to do.

Re:pretty quick on the C++14 support (1)

kthreadd (1558445) | about a year ago | (#45890827)

A free software license does not limit what you can do with the code. For all intents and purposes Apple could have released their code under GPLv3+ and they would have been fine. I totally understand why they choose not to do that, but it was Apples choice to do it; they could have done different if they really, really, really wanted to.

Re:pretty quick on the C++14 support (3, Insightful)

jo_ham (604554) | about a year ago | (#45891153)

A free software license does not limit what you can do with the code. For all intents and purposes Apple could have released their code under GPLv3+ and they would have been fine. I totally understand why they choose not to do that, but it was Apples choice to do it; they could have done different if they really, really, really wanted to.

And then shipped it together as a bundle with Xcode? The GPLv3 specifically prevents them doing that, and it was deliberately written that way. The GPLv3 absolutely limits what you can do with that code. It is a very restrictively and carefully written licence in certain very key areas (not that this is necessarily a bad thing if you want such a thing - and there are valid reasons for it existing).

So, no Apple couldn't have done that "if they really wanted to", without making the whole of Xcode open source.

That's not really "choice" and "freedom" is it? That's what this comes down to - the GPL protects the freedom of the *code* whereas the BSD licence protects the freedom of the *users and/or developers* of that code.

Re:pretty quick on the C++14 support (1)

kthreadd (1558445) | about a year ago | (#45891283)

I think you misunderstood me. My point was that Apple could choose to adhere to the license. They could join the GNU project if they wanted, or hire Richard Stallman as their CEO for all I know. I don't know if he would accept that position though. But the point is that nothing stops Apple from becoming the next Red Hat apart from artificial constraints about what Apple can or cannot do.

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45892631)

It's a pretty bloody facile point you're making, then.

Re:pretty quick on the C++14 support (3, Interesting)

phantomfive (622387) | about a year ago | (#45891835)

And then shipped it together as a bundle with Xcode? The GPLv3 specifically prevents them doing that, and it was deliberately written that way.

Wait, how does GPLv3 prevent them from shipping it in a bundle with Xcode? I'm pretty sure that's allowed under GPL3, but Apple didn't like the patent clauses.

Re:pretty quick on the C++14 support (2)

vakuona (788200) | about a year ago | (#45892533)

As I understand it, it is not possible to integrate GCC into Xcode in the same way as LLVM is without having to license Xcode as GPLv3 or some other compatible license. For example, Xcode uses (if I am not mistaken) the LLVM/CLang API. I don't think GCC has one, and if it had one, I don't think Apple could use it without having to change their Xcode license.

Re:pretty quick on the C++14 support (2, Interesting)

Anonymous Coward | about a year ago | (#45892605)

As an Xcode user I would definitely appreciate it if they released Xcode under GPL. Can't tell you the number of times I sworn about bugs in Xcode, taken the time to file the bug report just to get it closed immediately because it was a duplicate of some existing bug that I'm not allowed to see and then wait months or even years for a fix. Yes this is so important for me that I would happily jump in and fix the bugs myself. I have absolutely no interest in Xcode remaining closed source. None.

Re:pretty quick on the C++14 support (2)

jo_ham (604554) | about a year ago | (#45894187)

And then shipped it together as a bundle with Xcode? The GPLv3 specifically prevents them doing that, and it was deliberately written that way.

Wait, how does GPLv3 prevent them from shipping it in a bundle with Xcode? I'm pretty sure that's allowed under GPL3, but Apple didn't like the patent clauses.

The anti-Tivo clause, written exactly because of the perceived "weakness" of GPLv2 (insofar as it allowed more freedom to the sorts of developers that the writers of the GPL dislike) that enabled closed-sourced pieces of code and hardware that are part of a product to be kept back, while the (now essentially less useful without the closed bit) code could be released following the letter of the licence.

Xcode is not open source, but parts of it are. Given the way that the compiler is heavily integrated into it, using a GPLv3 licenced one would simply be infeasible, given that the whole of the source is not available.

Re:pretty quick on the C++14 support (1)

zakkudo (2638939) | about a year ago | (#45894675)

That's what this comes down to - the GPL protects the freedom of the *code* whereas the BSD licence protects the freedom of the *users and/or developers* of that code.

The GPL protects freedom in the same ways that the United States has laws and a constitution to protect freedom. BSD protects freedom in the same way that the public domain protects freedom.

Given how things are getting snatched out of the public domain, that security doesn't mean much. When a BSD project becomes large enough to be sued for patent infringment, good luck with that.

Let's flip your words and see how the quote change (1)

zakkudo (2638939) | about a year ago | (#45894719)

The GPL was explicitely written to protect developers and users, ensuring that they could modify software and mod it if it ever became unmaintained or whatever. Your example can have the words switched and few people would ever notice.

That's not really "choice" and "freedom" is it? That's what this comes down to - the BSD license protects the freedom of the *code* whereas the GPL protects the freedom of the *users and/or developers* of that code.

Re:pretty quick on the C++14 support (2)

Goaway (82658) | about a year ago | (#45893411)

For all intents and purposes Apple could have released their code under GPLv3+ and they would have been fine.

Not really. They, like many other companies, were not comfortable with the language about patents in GPL3, and did not want to take on the extra legal risk it involves.

Re:pretty quick on the C++14 support (5, Insightful)

Above (100351) | about a year ago | (#45890235)

There actually is a good reason.

Let's say a company invents a proprietary bit of silicon, and wants a compiler for it. They may likely chose one that requires them not to spill the beans on their proprietary hardware in the process. So yes, it's true, you don't get the benefit of their "special sauce", but you were never going to get it anyway, so there is no loss.

However, that same company now has a lot of people using the code. It takes time and money to track separate changes, so if they find a bug in code not specific to their proprietary stuff they are likely to fix it, and submit it upstream so they don't have to maintain it going forward. That code will benefit you.

So basically, the people who find the GPL odious will never use gcc, and will find some alternative. Given those people have fully closed options (license Intel's compiler, or Microsoft's), or use something like LLVM. With the LLVM model they can submit fixes to their non-secret sauce upstream, as well as get others to help fix problems they find in the non-secret sauce part.

TL;DL, if you choose gcc or LLVM you're never getting their secret sauce, but if you choose LLVM you get more help on the non-secret sauce parts.

That is the real essence of the "BSD License" philosophy. You may or may not agree.

Re:pretty quick on the C++14 support (2)

WilyCoder (736280) | about a year ago | (#45890687)

please, PLEASE say secret sauce one more time

He can't (1)

cripkd (709136) | about a year ago | (#45891249)

The license for the comment on which his comment is based forbids him from saying "secret sauce" one more time unfortunately.

Re:pretty quick on the C++14 support (1)

Above (100351) | about a year ago | (#45893951)

secret sauce

Re:pretty quick on the C++14 support (1)

peppepz (1311345) | about a year ago | (#45891593)

As a user of the proprietary bit of silicon, because of the BSD license, I don't get a compiler for my machine at all, unless I pay for the company's proprietary one (if that is an option).

This is something that bites me continuously with Android phones: manufacturers will only release the GPL licensed bits, so if I want to run my own software on the phone, I can only get crippled functionality because of all the bits I'm missing (Android has a no-GPL-in-userspace policy).

Re:pretty quick on the C++14 support (1)

kthreadd (1558445) | about a year ago | (#45891671)

And these proprietary bits would somehow be released under GPL if the BSD license did not exist?

Re:pretty quick on the C++14 support (2)

peppepz (1311345) | about a year ago | (#45895459)

It's not a matter of the existence of the BSD license. The key is the license of the most competitive project. Keep looking at Android as an example: Google dislike the GPL, so if some BSD kernel was on par with Linux for embedded devices, they would certainly have chosen that kernel instead. And we wouldn't even get device vendors to release the kernels.

Look at the Darwin kernel as another real-world example. Its source as released by Apple doesn't even boot nowadays, so the open source community around the Darwin kernel is very small if any.

Re:pretty quick on the C++14 support (1)

Above (100351) | about a year ago | (#45891985)

Your recourse is to not buy that thing that lacks source, regardless of license.

If LLVM (or some viable BSD licensed thing) did not exist these companies wouldn't flock to GNU, they would rather flock to Intel, Microsoft, or a host of others that will allow them to keep the technology from you.

The only way the GNU folks get what they want (all code under GNU licenses) is if all other licenses cease to exist or are outlawed . Provided there is an alternative, from a private licensing deal, or BSD code, or whatever, folks will be able to avoid the GNU license and thus avoid sharing.

GNU: All or nothing. BSD: We'll take as much as we can get.

Re:pretty quick on the C++14 support (1)

peppepz (1311345) | about a year ago | (#45895499)

Flock to GNU, I don't know. They would certainly consider it, since the licenses of Intel, Microsoft et al cost them money, a fact that companies are very sensitive to. And after they pay that money, they get a proprietary license that is certainly far more restrictive than the GPL.

The GNU folks "got what they wanted" when Tiemann added C++ to gcc because of the GPL license. Same thing happened with Jobs and Objective C. The GPL is proven to work, and it especially used to work back in the days when spreading FUD about the GPL wasn't fashionable.

About not buying stuff that I don't get source code for: that can only be a philosophical proposition in today's world. The GPL is a bastion to keep our devices hackable, and as you say BSD-licensed code will make the situation worse.

Re:pretty quick on the C++14 support (1)

Jartan (219704) | about a year ago | (#45892433)

The GPL doesn't have anything to do with it. RMS won't even allow simple command line features that could be "used" by a proprietary IDE for instance.

It's an understandable stance but the result is inferior software.

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45893793)

But you don't contribute to gcc, do you? No one wants to make a hippo dance.

Re:pretty quick on the C++14 support (5, Interesting)

serviscope_minor (664417) | about a year ago | (#45889063)

Yet another good readon for everyone to drop GCC and move on to the future. GCC is obsolete in pretty much every aspect,

Pure FUD. Who the hell modded this up. It's just plain trolling. GCC and LLVM are neck and neck, with GCC winning in the quality of the optimizer. I've also had compiler crashes much more recently with LLVM than with GCC, so it seems that GCC is also somewhat more battle hardened.


and the non-permissive license makes it hard to use for other purposes than simple command-line compilation compared to LLVM which can be integrated in many different products.

Only if you want to make your other tool non-free. Otherwise GCC works just fine.

Re:pretty quick on the C++14 support (3, Informative)

Anonymous Coward | about a year ago | (#45889167)

Only if you want to make your other tool non-free. Otherwise GCC works just fine.

You don't have to go as far as non-free. Projects that are non-GPLv3+ can't easily integrate with it. Even free software projects would benefit if GCC was at least LGPL since that allows code linking.

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45889915)

You know, you can just invoke GCC as a separate process and use pipes for interprocess communication (eg. errors reported by GCC). This in itself is not linking and is not affected by GPL. There is not much reason to linking with GCC except if you want to rebrand GCC for your own purposes.

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45890223)

I am confused - isn't this exactly the sort of thing the GCC Runtime Library Exception [gnu.org] exists for?

Re:pretty quick on the C++14 support (2)

kthreadd (1558445) | about a year ago | (#45890855)

No, that is not the same thing. The runtime library exception is for the parts of gcc that gcc includes in your program when it builds it. The actual binary that the compiler produces. This is limited to certain headers and library routines. It does not give you access to the inner workings of the compiler.

Re:pretty quick on the C++14 support (0)

fnj (64210) | about a year ago | (#45889797)

Absolutely correct that gcc and clang are nech and neck. One leapfrogs the other, or at the very least matches it with respect to tracking the evolving c++ standard, with each release.

Re the license, GPL is not as free as BSD, end of story.

Re:pretty quick on the C++14 support (1)

Trepidity (597) | about a year ago | (#45890639)

I'd personally like something freer than both GPL and BSD: a license that lets you do anything you want, except sue a downstream user of the software for copyright infringement. GPL lets you sue someone if they don't comply with precise release semantics, and BSD lets you sue someone if they use your "proprietary extensions" without a license from you. A free license would ensure that downstream users cannot be sued. The only freedom that license would take away is the freedom to sue other people, which is not a freedom worth retaining.

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45890881)

That's what the "public domain" is.

Re:pretty quick on the C++14 support (1)

Trepidity (597) | about a year ago | (#45891161)

No, if I release content into the public domain, a downstream user can still add proprietary extensions to it, and then sue reusers who use that fork without a icense. I'd like to license my software under a license that allows downstream users to do anything they want, except sue another downstream user.

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45891505)

(Same AC here.)

Interesting idea, but not really all that useful in practice. Most people that want to take source code and incorporate proprietary extensions are going to be unwilling to give up their rights to protect that code. (Even if they don't release the source themselves, they're going to want to protect it from theft or otherwise (by hackers/insiders, etc.)) Thus, such a license is as onerous to such a party as the GPL is.

On the flip side, someone who doesn't care about enforcement rights is probably also willing to release the underlying source code.

I suppose there is a small set of people who care to keep their own code private, but don't care to enforce their rights if their source gets used. But I would imagine that set is very small. I could be wrong.

I suppose you could also write a license that protects the right to sue in certain situations, but it's still hard to such a license getting traction, especially as it would get seriously complicated.

Re:pretty quick on the C++14 support (2)

gnasher719 (869701) | about a year ago | (#45892231)

No, if I release content into the public domain, a downstream user can still add proprietary extensions to it, and then sue reusers who use that fork without a icense. I'd like to license my software under a license that allows downstream users to do anything they want, except sue another downstream user.

So what if the next downstream user doesn't conform to the license by suing someone, what are you going to do? Sue them?

This is seriously a difficult problem. When you give your software to soeone else, you can either give them a license, or enter a contract. If there is a contract then you can actually force them to do something (like force them not to sue somebody else), but you may have to go to court to force them. If there is a license, then you can't force them to do anything. You can take them to court for copyright infringement if they don't conform to the license; that's how GPL works.

Re: pretty quick on the C++14 support (2)

AvitarX (172628) | about a year ago | (#45893019)

Can users of gpl software be sued? I thought only distributers ( I guess with web apps thats murkey though)

Re: pretty quick on the C++14 support (1)

fnj (64210) | about a year ago | (#45895171)

It depends on definitions. If NetFucker Inc. uses GPL software in a router they sell, who is the "user" of the GPLed software - NetFucker, or the end user of the router? Or both?

GPL is a license that says what you can and can't do with the software. Anyone who violates any of the terms of the license is at liability. Having said that, I don't think the "distributor" label is of significance except as an aid to visualization. it is hard to see a likelihood for the ultimate end user to ever to be in violation. I am not aware of any cases where legal proceedings were brought to bear on an ultimate end user. It's not like the decrepit SCO end game debacle.

Re:pretty quick on the C++14 support (1)

Kremmy (793693) | about a year ago | (#45889067)

I do hope you have sufficient understanding that the ideas you're espousing are directly at fault for how screwed up the technological climate is right now. Apple, Microsoft, Canonical, all changing up and breaking their products. GCC has issues, number one being this push to drop it off the wayside like the rest of the foundations of modern computing.

The One True Way (2)

zakkudo (2638939) | about a year ago | (#45889963)

I honestly don't think that GCC was made for you, Anonymous Coward. But that is also why it's nice that there are various options in the open source community...

I personally love command line compilation with gcc. Command line being a first class citizen means it's command line interface won't atrophy into a toy.

Re:The One True Way (0)

Anonymous Coward | about a year ago | (#45890001)

Did you just call clang(1) a toy? Well, then let me tell you I enjoy playing with my toy. =)

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45889991)

GCC is obsolete in pretty much every aspect, and the non-permissive license makes it hard to use for other purposes than simple command-line compilation compared to LLVM which can be integrated in many different products.

That's a bold statement with absolutely no proof. If GCC was obsolte "in pretty much every aspect", it wouldn't be in use. Open source community is not as conservative as proprietory enterprise so no one's stoping people from switching to Clang any time. I couldn't care less about gcc's license not permitting it to integrate with some hypothetical different products - all I need it to do is compile my code which it does well enough. Also, GCC is not just C and C++.

Code Completion? Static Analysis? (4, Informative)

glennrrr (592457) | about a year ago | (#45890283)

What's the code-completion situation in GCC these days, or the static analyzer situation? (I don't know.) Apple went with Clang at least in part because of not being able to get those features out of GCC without making Xcode GPL3 compliant, but I'd guess that an IDE with a compatible license might have a better shot at getting that information out of GCC. Code completion and static analysis are 2 of the great features of Xcode; I wouldn't want to go back to tools that didn't have either.

Re:Code Completion? Static Analysis? (1)

Anonymous Coward | about a year ago | (#45890899)

So can I build a cross-compiler toolchain for AVR micros with Clang yet?

Re:Code Completion? Static Analysis? (0)

Anonymous Coward | about a year ago | (#45896519)

What you need is an LLVM-IR to AVR backend. http://sourceforge.net/projects/avr-llvm/ seems to be one that is ~95% complete and just needs to be brought into the main LLVM project. Or you can just compile this yourself.

Re:Code Completion? Static Analysis? (1)

Anonymous Coward | about a year ago | (#45891217)

What's the code-completion situation in GCC these days,

Didn't you read? He only wants to compile his code, not to write it. ;-)

Re:Code Completion? Static Analysis? (0)

Anonymous Coward | about a year ago | (#45891673)

Yeah, very funny. Just FYI, GCC is GNU Compiler Collection. Last time I checked a compiler didn't have to perform static analysis and provide code completion to third party apps. These are nice-to-have's but they are not even part of compiling source code and no sane person would call a compiler obsolete because it doesn't do those things. Might as well call Clang obsolete and useless because it doesn't do Java, Ada, Fortran, etc.

Re:Code Completion? Static Analysis? (1)

glennrrr (592457) | about a year ago | (#45892031)

So, if you don't like the word obsolete, what word would you prefer? Deficient? The problem as I understand it, and I'm not claiming any expertise in compiler design, is that GCC is deliberately architected to prevent useful re-use of the code which can syntactically analyze source code which shows up in the difficulty in using it to integrate it with an IDE in terms of things like error parsing, code completion, and static analysis. As a long time Xcode user, I can remember when Xcode's code completion was abysmal, and I can remember first running the new static analyzer on my then big source base and finding dozens of problems; problems I could fix before they were hard to reproduce errors seen by users. The difference between Xcode running LLVM/Clang and GCC is just night and day in terms of delivering on the promise and feature set of a modern IDE. I tend to think that if you had access to those features in your GCC centric environment, you'd quickly find them essential.

Re:Code Completion? Static Analysis? (1)

Anonymous Coward | about a year ago | (#45892393)

I prefer judging a product based on its intended use. GCC is not an IDE, GCC is a set of compilers. Nowhere does it market itself as a complete software development solution that includes static analysis and code completion because those are historically features common to IDEs. You wouldn't call "ls" obsolete or deficient because it doesn't have "grep" functionality, would you? I don't have any evidence that GCC was deliberately architected to prevent any functionality from being implemented - do you? I don't believe projects like this are ever designed to impose such kinds of restrictions - it's not Microsoft, it's GNU. I could believe they probably didn't think about such features 20-30 years ago when GCC was originally designed and now there is either not that much demand for it within the GCC community or no resources to implement it or there may be a number of other reasons. Clang/LLVM were designed differently and they are delivering a great product, but in no way does that make GCC obsolete or deficient in areas it doesn't attempt to cover. As for Xcode, it's Mac only which is of no use to me - does it make Xcode obsolete or deficient? It's certainly useless for me no matter how good Clang is.

Re:Code Completion? Static Analysis? (2, Informative)

Anonymous Coward | about a year ago | (#45892947)

I don't have any evidence that GCC was deliberately architected to prevent any functionality from being implemented - do you? I don't believe projects like this are ever designed to impose such kinds of restrictions - it's not Microsoft, it's GNU.

A great deal of thought goes into the GCC license and GCC APIs that are exposed to third parties. Have a look at this [lwn.net] and this [lwn.net] . It is true that GCC has been designed and licensed to prevent integration with proprietary tools; Stallman et al. will not tolerate having GCC wired into some proprietary, closed source IDE and that fact guides their decisions about what APIs GCC provides and how GCC is licensed.

The `proprietary' part was left out by the GP and others that make the claim that GCC is designed to prevent third party integration.

Re:Code Completion? Static Analysis? (0)

Anonymous Coward | about a year ago | (#45895107)

I have no problem with a GPL project not bending over to deliver free functionality to be used in proprietary products.

Re:Code Completion? Static Analysis? (1)

kthreadd (1558445) | about a year ago | (#45892033)

Might as well call Clang obsolete and useless because it doesn't do Java, Ada, Fortran, etc.

The C in Clang stands for C, so it will probably never support those other languages. That's because Clang is just a frontend to LLVM. There are other frontends that implement those languages. Even GCC can act as a frontend to LLVM.

Re:Code Completion? Static Analysis? (0)

Anonymous Coward | about a year ago | (#45892213)

Just as well, the first C in GCC stands for compiler, not everything-you-would-ever-need-to-write-software.

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45891685)

> and the non-permissive license makes it hard to use for other purposes

LLVM / Clang's acceptance of patent encumbered code from Apple, Qualcomm, and others makes LLVM technically unlawful to use for anyone who doesn't have a cross license agreement with these corporations. If LLVM was intended to be usable by others it would at least be under the Apache license so that contributors had to at least offer you a license to use the code they contributed in LLVM itself.

Sure, for now they're not enforcing but GCC isn't dead yet and it still produces faster, tighter code, so it isn't a big deal to drop LLVM for GCC. That won't remain true if people follow your advice.

Re:pretty quick on the C++14 support (2)

Guy Harris (3803) | about a year ago | (#45892959)

LLVM / Clang's acceptance of patent encumbered code from Apple, Qualcomm, and others makes LLVM technically unlawful to use for anyone who doesn't have a cross license agreement with these corporations.

The LLVM Developer Policy page section on patents [llvm.org] says:

If you or your employer own the rights to a patent and would like to contribute code to LLVM that relies on it, we require that the copyright owner sign an agreement that allows any other user of LLVM to freely use your patent. Please contact the oversight group for more details.

Are you saying that Apple, Qualcomm, and others have not signed such an agreement? Or are you saying that such an agreement isn't sufficient to allow anyone who doesn't have a cross-license agreement with the patent holders to use LLVM?

Re:pretty quick on the C++14 support (1)

Anonymous Coward | about a year ago | (#45892727)

LLVM still makes sub par compiled code. Who cares that it takes less time to compile, its execution & size performance is awful, worse than GCC which is awful compared to most commercial compilers. This is especially true for ARM based instruction sets (VC & ICC do better for x86 as well). And the fact 'Apple' does it, is not a valid reason to do anything.

Don't get me wrong, LLVM is a cool tool and great for debug code generation especially because all sorts of metric/instrumentation can be done with it, but as a compile to replace GCC would be a down grade and a compilers NUMBER ONE goal is to compile better machine code!

Re:pretty quick on the C++14 support (0)

Anonymous Coward | about a year ago | (#45894601)

Not always. It might make sense, for example, to use LLVM to do developer / debugging builds, and GCC + LTO for optimized release builds. If it shaves off five seconds per edit-compile-test cycle, it can be a productivity gain.

(Of course, what I end up doing is to just switch between the two since they produce different error messages, and sometimes one will hint at the problem better than the other, especially when playing around with heavily templated code...)

Not really obsolete (2)

aaaaaaargh! (1150173) | about a year ago | (#45892889)

For example, I'm sometimes programming in Ada, which clang doesn't really compile (at least when I looked last time). Moreover, gcc with -O2 or -O3 produces faster executables on my machine.

How to always skip Slashdot Beta (0, Informative)

Anonymous Coward | about a year ago | (#45888895)

Re:How to always skip Slashdot Beta (1)

Anonymous Coward | about a year ago | (#45889539)

Better yet, instead of having to append something to the url every time, just delete the betagroup cookies.

Re:How to always skip Slashdot Beta (2, Informative)

Anonymous Coward | about a year ago | (#45889695)

thanks alot, the beta is awful

LOL ... (1, Funny)

gstoddart (321705) | about a year ago | (#45888915)

Every time I see that project name, I immediately think of the Simspons doing "Clang Clang went the trolley".

Re:LOL ... (0)

Anonymous Coward | about a year ago | (#45889029)

I must be old, I think of Judy Garland.

Re:LOL ... (1)

gstoddart (321705) | about a year ago | (#45889053)

I must be old, I think of Judy Garland.

Much funnier when the Simpsons did it.

Everytime I see the word Clang (0)

Anonymous Coward | about a year ago | (#45892093)

I think that it is a Klingon word and needs to be translated..
Does this happen to anyone else?

No? It must just be me..

Mingw builds (1)

FithisUX (855293) | about a year ago | (#45894111)

They seem to have stopped mingw builds and focus on clang-cl on windows. The problem is that you need the Windows SDK. With most other open source / free compilers this is not necessary. Personally I use mingw in both of its incarnations and the problem is that I cannot download a ready made binary. clang-cl is unusable without windows sdk. It is not compatible with lcc,pelles,openwatcom,digital mars c SDKs.

Re:Mingw builds (1)

Anonymous Coward | about a year ago | (#45895397)

So, since you're programming on Windows anyway, what's the problem with downloading and installing the Windows SDK? It's available from the MS site without registration or fees.

- T

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?