View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0013616 | Scribus | Build System | public | 2015-12-24 12:55 | 2016-11-11 22:54 |
Reporter | AMDmi3 | Assigned To | cbradney | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Platform | amd64 | OS | FreeBSD | OS Version | 10.2 |
Product Version | 1.4.5 | ||||
Summary | 0013616: In-source build installs unwanted files | ||||
Description | In-source and out-source cmake builds install different sets of files and directories, including: include/scribus/plugins/barcodegenerator/ui_barcodegenerator.h include/scribus/plugins/colorwheel/ui_cwdialog.h include/scribus/plugins/fontpreview/ui_fontpreview.h include/scribus/plugins/pixmapexport/ui_exportform.h ... include/scribus/ui_aboutplugins.h include/scribus/ui_aligndistribute.h include/scribus/ui_charselect.h include/scribus/ui_charselectenhanced.h include/scribus/ui_cmsprefsbase.h ... include/scribus/CMakeFiles/scribus.dir/downloadmanager include/scribus/CMakeFiles/scribus.dir/tt/simpletreemodel include/scribus/CMakeFiles/scribus.dir/ui include/scribus/colormgmt/CMakeFiles/scribus_colormgmt_lib.dir include/scribus/desaxe/CMakeFiles/scribus_desaxe_lib.dir ... This is incorrect. I haven't checkd but usually these come from using GLOB in CMakeLists.txt You should either not use globs or explicitly forbit insource builds. | ||||
Steps To Reproduce | Build/install insource and outsource, compare. cd scribus mkdir build cd build cmake -DCMAKE_INSTALL_PREFIX=/tmp/outsource && make install cd .. rm -rf build cmake -DCMAKE_INSTALL_PREFIX=/tmp/insource && make install | ||||
Tags | No tags attached. | ||||
Patch | No | ||||
related to | 0013751 | closed | Crash after r21013 |
|
If you're doing in source builds you already don't care about mess. The ui files are generated by the moc app so this is normal. |
|
There's nothing wrong in in source builds unless the build system is broken, and doing in-source build absolutely doesn't mean one "doesn't care about mess". You should either support proper in-source build or explicitly disable it. |
|
if in-source build do not work correctly it should imo indeed disabled... http://stackoverflow.com/questions/1208681/with-cmake-how-would-you-disable-in-source-builds |
|
Sorry, but I dont think you understand how Qt works. The ui_ files are generated in the build process. This is perfectly normal. |
|
AMDmi3, can you please specify what the real problem is? is there something that is not working in one of both cases? |
|
I know pretty well how Qt works, and I think I've already explained the problem. The problem is that uic-generated header files are installed in the case of in-source build and are not installed in the case of out-source build, so either of builds is broken. Also, in case of in-source build, CMake-generated directories are also installed which is broken as well. I've investigated some more, and it turns that ui_ files are referenced by other installed includes, so in-source build is definitely broken as it does not install all the headers. The culprit is scribus/CMakeLists.txt: INSTALL(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/ DESTINATION ${INCLUDEDIR} For in-source build, it installs unneeded cmake directories, for out-source build, it doesn't install needed generated headers. That exactly is the problem. Both cases can be fixed by switching it to INSTALL(FILES ...) with explicitly defined set of header files, which include static and generated ones. Additionally, if you officially do not support in-source builds, they indeed should be explicitly disabled, just as ale mentioned in #0038638. |
|
in-source build is a bad idea so almost nobody does and it might be untested. since you don't provide any evidence of a problem, i have now to get a fresh svn checkout and do an in-source build... but, next time, please provide facts, not conjectures... |
|
ok, cmaked, maked, make installed, runned. works as expected. again: what is the/your problem? out-source obviously works. in-source seems to be working. have you tried yourself? have you spot any *real* problem? files being at a different place (or not being there since they might be managed differently) is not a reason for hyperventilating... all in all, in-source building is not good practice, but i don't think scribus should prevent it, if there is no error. (if ever, it's cmake that should "forbid" it...) |
|
in-source building has been disabled... but it seems to trigger problems with travis... |
|
in-source building has been enabled again. because travis and homebrew need it. so: is there a problem with in-source building? AMDmi3, can you please point us to any real problem you see with the in-source building? |
|
I've already explained it two times, you seem to deliberately ignore it. This is the final attempt. Run from scribus repo root: #!/bin/sh mkdir build cd build cmake -DCMAKE_INSTALL_PREFIX=/tmp/scribus.outsource -DWANT_HEADERINSTALL=YES .. make make install cd .. cmake -DCMAKE_INSTALL_PREFIX=/tmp/scribus.insource -DWANT_HEADERINSTALL=YES . make make install cd /tmp/scribus.outsource && find -s . > /tmp/scribus.outsource.list cd /tmp/scribus.insource && find -s . > /tmp/scribus.insource.list diff -u /tmp/scribus.outsource.list /tmp/scribus.insource.list Problem 1: prefix for insource build DOES contain cmake-generated garbage directories, while it SHOULD NOT: +./include/scribus/CMakeFiles +./include/scribus/CMakeFiles/scribus.dir +./include/scribus/CMakeFiles/scribus.dir/downloadmanager +./include/scribus/CMakeFiles/scribus.dir/imagedataloaders +./include/scribus/CMakeFiles/scribus.dir/third_party ... +./include/scribus/third_party/wpg/CMakeFiles/scribus_wpg_lib.dir +./include/scribus/third_party/zip/CMakeFiles +./include/scribus/third_party/zip/CMakeFiles/scribus_zip_lib.dir +./include/scribus/ui/qml/CMakeFiles +./include/scribus/unicodemap/CMakeFiles Problem 2: prefix for outsource build DOES NOT contain uic headers, while it SHOULD, as they are referenced from other headers: +./include/scribus/plugins/barcodegenerator/ui_barcodegenerator.h +./include/scribus/plugins/colorwheel/ui_cwdialog.h +./include/scribus/plugins/export/pixmapexport/ui_exportform.h +./include/scribus/plugins/fontpreview/ui_fontpreview.h +./include/scribus/plugins/import/pdf/ui_pdfimportoptions.h ... +./include/scribus/ui_transformdialogbase.h +./include/scribus/ui_transparencypalette.h +./include/scribus/ui_unicodesearch.h +./include/scribus/ui_useprintermarginsdialog.h +./include/scribus/ui_weldeditbase.h |
|
AMDmi3, you're only showing the differences between the two trees, but now telling us what the problem is! a difference is not a problem. it might be different and still be correct. can you provide a patch that shows how to fix that? |
|
> a difference is not a problem No. A difference solely is definitely an indication of broken build system. > can you provide a patch that shows how to fix that? No. I gave a hint in #0038680 |
|
case closed, for what i'm concerned... (this time i might be happy with a broke systen, if if works flawlessly on every computer :-) |
|
Of course the out of source build contains the ui files.. look in the scribus directory. AND of course the in source build contains generated files - this is the reason to not use in source builds - you get build stuff put in there! Both work fine, but one leaves a mess lying around and when you want to clean up, its hard. Also, out of source builds don't allow multiple build setups from one source tree. We'll be disabling in source builds as soon as we can though. |
|
> Of course the out of source build contains the ui files But it doesn't install them. |
|
i don't think that the ui files have to be installed. afaik they are only used by the pre-processor and transformed in .h files... |
|
Of course we do not install the generated ui related files. They are not needed after the build is complete. |
Date Modified | Username | Field | Change |
---|---|---|---|
2015-12-24 12:55 | AMDmi3 | New Issue | |
2016-02-10 21:52 | cbradney | Note Added: 0038632 | |
2016-02-10 21:52 | cbradney | Status | new => resolved |
2016-02-10 21:52 | cbradney | Resolution | open => won't fix |
2016-02-10 21:52 | cbradney | Assigned To | => cbradney |
2016-02-10 22:53 | AMDmi3 | Note Added: 0038636 | |
2016-02-10 22:53 | AMDmi3 | Status | resolved => feedback |
2016-02-10 22:53 | AMDmi3 | Resolution | won't fix => reopened |
2016-02-11 09:24 | ale | Note Added: 0038638 | |
2016-02-11 22:36 | cbradney | Note Added: 0038650 | |
2016-02-12 09:55 | ale | Note Added: 0038660 | |
2016-02-12 21:13 | AMDmi3 | Note Added: 0038680 | |
2016-02-12 21:13 | AMDmi3 | Status | feedback => assigned |
2016-02-13 08:56 | ale | Note Added: 0038691 | |
2016-02-13 09:16 | ale | Note Added: 0038692 | |
2016-02-17 09:36 | ale | Note Added: 0038807 | |
2016-02-18 09:26 | ale | Note Added: 0038826 | |
2016-02-18 12:02 | AMDmi3 | Note Added: 0038828 | |
2016-02-18 13:04 | Kunda | Relationship added | related to 0013751 |
2016-02-18 14:33 | ale | Note Added: 0038830 | |
2016-02-18 14:54 | AMDmi3 | Note Added: 0038831 | |
2016-02-18 15:51 | ale | Note Added: 0038832 | |
2016-02-18 15:53 | ale | Note Edited: 0038832 | |
2016-02-19 06:13 | cbradney | Note Added: 0038838 | |
2016-02-19 10:34 | AMDmi3 | Note Added: 0038839 | |
2016-02-22 09:22 | ale | Note Added: 0038858 | |
2016-03-07 23:13 | cbradney | Note Added: 0039036 | |
2016-05-26 22:45 | cbradney | Status | assigned => resolved |
2016-05-26 22:45 | cbradney | Resolution | reopened => no change required |
2016-11-11 22:54 | cbradney | Status | resolved => closed |