Review Request 127638: build system option to build "kdev-clang" and the rest of the IDE separately

[Kevin Funk]

> On April 12, 2016, 9:31 p.m., Milian Wolff wrote:
> > -2
> > 
> > the ide without the plugins is unusable, this patch makes zero sense to me.
> > 
> > also note that you can already disable sub folders if you really want to do that (I doubt it). Just look at the cache via ccmake e.g.:
> > 
> > ```
> >  BUILD_TESTING                    ON
> >  BUILD_clang                      ON
> >  BUILD_cmake                      ON
> >  BUILD_cmakebuilder               ON
> >  BUILD_custom-buildsystem         ON
> >  BUILD_custom-definesandinclude   ON
> >  BUILD_custommake                 ON
> >  BUILD_executeplasmoid            ON
> >  BUILD_ghprovider                 ON
> >  BUILD_kdeprovider                ON
> >  BUILD_kdev_includepathsconvert   ON
> >  BUILD_kdev_makefileresolver      OFF
> >  BUILD_kdev_msvcdefinehelper      OFF
> >  BUILD_manpage                    ON
> >  BUILD_plugins                    ON
> >  BUILD_qmake                      ON
> >  BUILD_qmake_parser               OFF
> >  BUILD_qmakebuilder               ON
> >  BUILD_qmljs                      ON
> >  BUILD_qthelp                     ON
> > ```
> 
> Aleix Pol Gonzalez wrote:
>     Agreed, I don't see the value in the patch either.
> 
> René J.V. Bertin wrote:
>     Have you even looked at what this does exactly? 
>     
>     > the ide without the plugins is unusable
>     
>     This patch *makes it possible* for someone *who has a reason to do so* to build the IDE with *all* plugins *except* the kdev-clang plugin. That leaves all other plugins, so the IDE should remain usable for everything that doesn't require libclang.
>     
>     This patch is intended as a convenience for packagers. It was *not* designed to allow installing the IDE *without* ever installing the corresponding kdev-clang plugin, only to be able to build and package the IDE and the plugin separately. With the emphasis on *build and*; in case it still isn't clear not all packaging/distribution systems support creating multiple packages from a single build.
>     
>     Do I have to understand that `-DKDEVELOP_BUILD_CLANG_PARSER=OFF` is equivalent to `-DBUILD_clang=OFF`? That isn't apparent from the CMake files.
> 
> Milian Wolff wrote:
>     Yes, you can use `-DBUILD_*=OFF` to disable features. It works for all others, so I suggest you fix your packaging system if it doesn't work. Worst-case, ship this patch there if you really need it. I don't want to maintain that in our code base.
> 
> René J.V. Bertin wrote:
>     It doesn't look there's a way to build only kdev-clang with that approach which isn't an option anyway because -DBUILD_clang=OFF does NOT disable the required dependency on clang.
>     
>     Let me ask something else just to know exactly how I might fix the (*NOT* _mine_) packaging system:
>     
>     how is the standalone-app-bundle build going to be implemented in the cmake files? Will it be a hardcoded choice (`if(APPLE)`) like the marble project currently does it? Or will it be under proper control of an option variable? That should be hardly any more complicated (`option(APPLE_BUILD_APPBUNDLE,"build as standalone app bundle",YES)` and then `if(APPLE_BUILD_APPBUNDLE)` for everything that's only related to install locations and not additional link properties). But the present patch isn't exactly complicated either ...

> It doesn't look there's a way to build only kdev-clang with that approach which isn't an option anyway because -DBUILD_clang=OFF does NOT disable the required dependency on clang.

Then do:
```
if (NOT BUILD_clang)
   find_package(...)
...
```


- Kevin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127638/#review94558
-----------------------------------------------------------


On April 12, 2016, 4:34 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127638/
> -----------------------------------------------------------
> 
> (Updated April 12, 2016, 4:34 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDevelop.
> 
> 
> Repository: kdevelop
> 
> 
> Description
> -------
> 
> This patch is in reaction to a discussion on kdevelop-devel about weakening KDevelop's dependency on a specific Clang (libclang) version.
> 
> The patch introduces 2 CMake options:
> - `KDEVELOP_BUILD_IDE` builds just the IDE, without the clang-based parser (formerly kdev-clang)
> - `KDEVELOP_BUILD_CLANG_PARSER` builds just the clang-based parser
> 
> Nothing changes when both options are on (the default): all of KDevelop is built. When both options are off, an error is raised.
> 
> The idea is that this should make it a little bit easier for distributions/packaging systems and users to change the clang toolchain.
> 
> I presume that the languages subdirectory could be built first or last (that would the patch a bit simpler)?
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 2d3faa7 
>   languages/CMakeLists.txt 4e2fde2 
>   languages/clang/CMakeLists.txt c19a951 
> 
> Diff: https://git.reviewboard.kde.org/r/127638/diff/
> 
> 
> Testing
> -------
> 
> On OS X and Linux, against Qt 5.6.0, FWs 5.20.0, prefix=/opt/local
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20170109/f611ab58/attachment.html>