[KDE/Mac] Review Request 127638: build system option to build "kdev-clang" and the rest of the IDE separately
René J.V. Bertin
rjvbertin at gmail.com
Thu Apr 14 10:56:53 UTC 2016
> On April 12, 2016, 11: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.
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 ...
- René J.V.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127638/#review94558
-----------------------------------------------------------
On April 12, 2016, 6: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, 6: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/20160414/712dd736/attachment-0001.html>
More information about the kde-mac
mailing list