Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Enhancements to the CB Build System
MortenMacFly:
Another thing I noticed: if you have two targets in a project that have a ui definition with the same name, the generated file is overwritten. Is there a particular reason why you use the project macro?
scarphin:
--- Quote from: MortenMacFly on April 19, 2015, 06:44:02 am ---Also, there was an issue if you load a project with a custom command that refers to a compiler probably not present on the target computer. make sure you always verify pointers! :-)
--- End quote ---
I've already fixed that one. ;)
--- Quote from: MortenMacFly on April 19, 2015, 06:44:02 am ---I think it's not an issue with the qt version but with the implementation. The object files for the second target don't go into the right folder, therefore the linker cannot find them.
--- End quote ---
Yes, it's not an issue with qt version but it's not an issue with the implementation either. The problem is after the first target generates the auto-generated file, the target(s) after that checks the previously generated file's timestamp to decide if the source file is outdated or not. As both targets generate the same file, second target and targets after that never build the file as its timestamp is never than the source. You can test this by checking 'clean and build all projects/targets one by one' in 'settings->compiler->build options' and rebuild 'all', all targets should get built. Introduction of $(target...) macros may solve this, I'm working on it.
--- Quote from: MortenMacFly on April 19, 2015, 06:48:17 am ---Another thing I noticed: if you have two targets in a project that have a ui definition with the same name, the generated file is overwritten. Is there a particular reason why you use the project macro?
--- End quote ---
I didn't quite get this. Are you asking why I used '$project_dir' instead of '$file_dir'? If yes, it's because of the need for a temporary folder for intermediate files (like outputs of ui, moc, rcc etc...). Generated files are always overwritten with CB's current implementation, I believe $(target...) macros will fix this.
oBFusCATed:
--- Quote from: scarphin on April 19, 2015, 11:53:52 am ---If yes, it's because of the need for a temporary folder for intermediate files (like outputs of ui, moc, rcc etc...). Generated files are always overwritten with CB's current implementation, I believe $(target...) macros will fix this.
--- End quote ---
Why aren't you using the object file folder for temporary files?
It is intended for temp files as .o files and it is known to be unique for different targets.
MortenMacFly:
--- Quote from: scarphin on April 19, 2015, 11:53:52 am ---
--- Quote from: MortenMacFly on April 19, 2015, 06:48:17 am ---Another thing I noticed: if you have two targets in a project that have a ui definition with the same name, the generated file is overwritten. Is there a particular reason why you use the project macro?
--- End quote ---
I didn't quite get this. Are you asking why I used '$project_dir' instead of '$file_dir'? If yes, it's because of the need for a temporary folder for intermediate files (like outputs of ui, moc, rcc etc...). Generated files are always overwritten with CB's current implementation, I believe $(target...) macros will fix this.
--- End quote ---
OK, I'll explain to better:
Assume you've a project with two targets each producing a single executable with a QT UI.
Now, if both targets may use a file named "app_ui" for their UI stuff "by accident" or "habbit".
This would mean that although these UI's share nothing in common and are not related either they will generate the same file in the same folder, thus the later target compiled will overwrite the previous'es generated file.
The reason is, that both targets will write into $project_dir which is the same for both.
Instead, it should be unique per target. As two targets within a project cannot have the same, the target name could/should be part of the output file/path for the generated file to avoid this... There might be another (better) solution though...
I hope you don't get de-motivated by such comments... but we want to make it good, do we? 8)
Besides: I still didn't figure out what to do to have a single QT (UI) executable with the required QT DLL's in a folder that works. I guess I am missing something completely: They still only run if I put them into QT's installations' "bin" folder.
I tried copying the Qt5Core, UI, Widgets and the platform DLL for Windows into the executable folder but that seems not to be enough... WTF! :-\
scarphin:
--- Quote from: oBFusCATed on April 19, 2015, 12:53:53 pm ---Why aren't you using the object file folder for temporary files?
It is intended for temp files as .o files and it is known to be unique for different targets.
--- End quote ---
Nice idea but I don't think that will make any difference because as I understand it, .o files are resolved and generated during compilation (I mean when CB starts compiling targets/project) so the path can be adjusted per target. Generated files however are added to the project with certain paths that need to be determined before adding the file, at least it's the current implementation. Another reason might be that not all generated files are object files so it may not be suitable to include an object folder to project search paths.
--- Quote from: MortenMacFly on April 19, 2015, 01:29:18 pm ---Assume you've a project with two targets each producing a single executable with a QT UI.
Now, if both targets may use a file named "app_ui" for their UI stuff "by accident" or "habbit".
This would mean that although these UI's share nothing in common and are not related either they will generate the same file in the same folder, thus the later target compiled will overwrite the previous'es generated file.
The reason is, that both targets will write into $project_dir which is the same for both.
Instead, it should be unique per target. As two targets within a project cannot have the same, the target name could/should be part of the output file/path for the generated file to avoid this... There might be another (better) solution though...
--- End quote ---
Ok, it's clear now. I think the ultimate solution is the target macros but I'm having some troubles implementing that, I'll need some time.
--- Quote from: MortenMacFly on April 19, 2015, 01:29:18 pm ---I hope you don't get de-motivated by such comments... but we want to make it good, do we? 8)
--- End quote ---
Not at all. I want these features to be solid and bug free as much as possible. I need these comments to accomplish that and considering your tests surfaced some issues which needs to be addressed, I'm even grateful. ;)
--- Quote from: MortenMacFly on April 19, 2015, 01:29:18 pm ---Besides: I still didn't figure out what to do to have a single QT (UI) executable with the required QT DLL's in a folder that works. I guess I am missing something completely: They still only run if I put them into QT's installations' "bin" folder.
I tried copying the Qt5Core, UI, Widgets and the platform DLL for Windows into the executable folder but that seems not to be enough... WTF! :-\
--- End quote ---
Well, I've never used qt5 but my guess is some dll mismatch. What error do you get when you try to run the executable from cb's output folder? Are you sure correct dlls are in path for the compiler's bin folder which is used to build the qt5 package? Maybe some other compiler's bin folder is getting priority over the correct one and wrong dlls are used by windows?! Have you tried it with qt4? Btw qt5 doesn't support win xp so I don't think it can be considered as the latest evolution of qt. qt4 is still being developed for win xp users, that's the reason I and many others still use qt4. I'll test the implementation with qt5 too after things are resolved.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version