<blockquote>
<p>It has annoying downsides like the need to setup a complete "project" with build options and all -- goodbye "build system is enough".</p>
</blockquote>

<p>This is exactly what I love about Geany - whatever sources you feed it with, it parses them without knowing how to build them - whatever build system is used. And most opensource projects use autoconf/automake and it's impossible to have a look at configure.ac all m4 and makefiles and know which way ti will be built this way (moreover it depends on what's installed in the system, the config flags given during configure etc.). So every project would have to be setup manually by providing all compiler flags, defines, dependencies, etc. That's undoable for anything bigger.</p>

<p>This doesn't mean I would be against e.g. the clang parser <a href="https://github.com/codebrainz" class="user-mention">@codebrainz</a> did but I'd really want to keep the current way of parsing preserved for people who want it for the reasons above (it could be disabled by a plugin if someone wishes to do something else).</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/geany/geany/pull/1188#issuecomment-242469268">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJzJbvTTHZWf91mVQ1JcxEm9aIQ9bks5qjc21gaJpZM4JqXyT">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJ51IuP4cCd75_7v0u2QTpTqrLhkOks5qjc21gaJpZM4JqXyT.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/geany/geany/pull/1188#issuecomment-242469268"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/geany/geany","title":"geany/geany","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/geany/geany"}},"updates":{"snippets":[{"icon":"PERSON","message":"@techee in #1188: \u003e It has annoying downsides like the need to setup a complete \"project\" with build options and all -- goodbye \"build system is enough\".\r\n\r\nThis is exactly what I love about Geany - whatever sources you feed it with, it parses them without knowing how to build them - whatever build system is used. And most opensource projects use autoconf/automake and it's impossible to have a look at configure.ac all m4 and makefiles and know which way ti will be built this way (moreover it depends on what's installed in the system, the config flags given during configure etc.). So every project would have to be setup manually by providing all compiler flags, defines, dependencies, etc. That's undoable for anything bigger.\r\n\r\nThis doesn't mean I would be against e.g. the clang parser @codebrainz did but I'd really want to keep the current way of parsing preserved for people who want it for the reasons above (it could be disabled by a plugin if someone wishes to do something else)."}],"action":{"name":"View Pull Request","url":"https://github.com/geany/geany/pull/1188#issuecomment-242469268"}}}</script>