STR #3249: Placing abi-version.h in the IDE folders breaks existing VS projects.

STR #3249

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	3 - Moderate, e.g. unable to compile the software
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Build Files
Summary:	Placing abi-version.h in the IDE folders breaks existing VS projects.
Version:	1.3-current
Created By:	Belgiansteve
Assigned To:	AlbrechtS
Fix Version:	1.3.4 (SVN: v11050)
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

No files

Trouble Report Comments:

#1	Belgiansteve 10:18 Aug 14, 2015

Hi, I use VS10 and VS13 and I was wondering why the abi-version.h file was placed in the IDE folders? Why can't it be located with the rest of the header files? Since the content of abi-version.h does not appear to depend on the IDE or OS, I find this a rather odd decision. For me, this change also meant that none of my VS projects that use fltk build anymore because none of my projects are setup to look for this new <IDE>\FL folder. If there is not a compelling reason for the current location of the abi-version.h file, I would like to recommend moving it to the usual place for fltk header files (that's what I did to get my projects to build and it seems to work just fine). Thanks, Steve

#2	AlbrechtS 11:31 Aug 15, 2015

Thank you for the report. The reason why abi-version.h is not in the FL/ directory is because this is a generated file in both the autoconf/configure and CMake build systems. Unfortunately the configure process stores the generated file in the FL/ directory of the source file system, but CMake stores it in its build tree (if properly used with out-of-source-tree builds). Having the "pre-generated" abi-version.h in <IDE>/FL was a compromise for the bundled IDE files. README.MSWindows.txt covers the "installation" process after building the FLTK library for use with other IDE projects. Note that the file can be different depending on configuration options, i.e. in case of IDE builds: manually edited before building the library. Can you tell us more about the way you build and use the FLTK libs in your projects? According to your description I assume that you: (1) use the bundled IDE project files to build the FLTK libs (2) do not "install" the libs anywhere (just build in the source dir) (3) have your own application IDE projects (workspaces) (4) use the built FLTK libs (step 1) in your IDE projects directly from their build location If all of this is true, then you have two choices: (a) add the <IDE> directory to the include search list in your project files (b) copy abi-version.h to the FLTK include directory FL/ as you seem to have done according to your description. I'd like to improve the documentation on this issue. Everything you can tell us about your usage pattern of the build-and-use FLTK process may help. BTW: I intend to add more documentation in the CHANGES file. This is on my todo list. TIA for all your comments.

#3	Belgiansteve 13:59 Aug 15, 2015

Hi Albrecht, thanks for your reply, but are you really suggesting that the "compromise" was to break all VS projects that use fltk only to include a file that for most people will be empty??? From what you are saying, placing the file in FL\ would work for everybody, except CMake users. I've never used CMake, but I would be very surprised if you could not copy that file into the FL\ folder prior to building fltk. Perhaps someone could look into that option? And besides, why was the previous approach replaced? Defining the ABI version inside Enumerations.h seemed to work just fine, didn't it? Again, since I think it's fair to say that most people don't really (and should not have to) care about the ABI version, I find the current approach rather cumbersome. I'm sure a better solution can be found. Thanks!

#4	AlbrechtS 16:26 Aug 15, 2015

Hi Steve, sorry, nobody anticipated that the approach taken would "break all VS projects that use fltk". Of course this was not intended. And with a change in the project's configuration (add another include directory) this could even be "fixed" [see below for my questions concerning this]. Otherwise, if somebody installed the built libs and include files, as described in the README, copying one more file as written in the README file would do the job. The reason the new configure and CMake option was introduced was (1) there was a user request, and (2) that editing a source file is never a good solution, because the next update would overwrite that source file. Additionally, (3) developers need to be able to use different configurations to test all ABI versions for better quality control. Especially the CMake approach is a good means to configure different build options. FYI: The way CMake works is NOT to touch the source directory tree. Never ever. In general the source tree could be read-only. Hence copying the file /into/ the source tree is not an option. Of course you could (if the source tree is not read-only), but then one of the major advantages of the CMake approach would not work: With CMake you can configure different build trees with different build options, including different ABI versions. In reality we could even have a default abi-versions.h in the source FL/ folder, but use another one in the build tree - it /would/ work, but it's strange to have two identically named files with different contents, although it would be doable. However, since I didn't anticipate to break anything, the other solution (as implemented in svn) seemed to be the better one to me. If this is not true we can of course think about a better one. However, to think about a better solution we need more information from our users. You're the first to find and report that this new solution broke his build(s), although it is now almost five weeks since the change (svn r 10786, 2015-07-12 21:23:55 +0200). Again, thanks for the report. I'm a little disappointed though that you did not even try to answer my questions. So again, can you please tell us how your typical usage pattern is? (see questions above) Note that I personally don't use MS IDE files, hence you can certainly better answer my questions about practical issues of this change. I assume you build FLTK only once. How many different projects would you have to change if you had to add an include directory? Would it be only one include directory change per workspace, or would you have to edit many projects in one workspace ("solution") to add an include directory? Hmm, trying to answer the last question myself: looking at the FLTK IDE (with Visual C++ 2008) it appears to me that I would have to change 79 projects * n build configurations, which would not be acceptable. If that is your issue, I can understand your problem better. Can you confirm that this is the reason? Or can you tell me what else would be your practical problems? Okay, that was a long post, late in the evening. Please try to answer my questions so we can make progress. Thanks.

#5	Belgiansteve 18:13 Aug 15, 2015

Hi Albrecht, Thanks for taking the time to respond. Sorry for not answering your questions, but like I already mentioned, my problem was solved by copying the file to the Fl folder. But since you asked, I build my code exactly as you guessed in your first response. I don't know exactly how many projects I would have to fix (presumably dozens) but I have no intention of changing any of them (especially since my solution works really well :) ) The point of my initial email was simply to point out that 1) this solution breaks existing VS projects and 2) in my honest opinion this is not really a solution. To make my point further, regarding your reasons for using CMake: 1) there was a user request Okay, fine. 2) that editing a source file is never a good solution, because the next update would overwrite that source file Fair enough, but your solution does overwrite abi-version.h which is now part of the source code (since it won't build without it). Even more, for IDE developers this file is versioned and has to be manually edited, so for IDE developers nothing has really changed (except that all of their projects broke of course :) ). 3) developers need to be able to use different configurations to test all ABI versions for better quality control. Very true, but that does not justify the approach taken. You could do this with the previous approach too. Again, for IDE developers such as myself, really nothing has changed. Anyways, I'd be curious to hear what other people think about this solution, but like I said, for me the issue is solved by copying that file to Fl, although I hope that you will take another look at the ABI versioning and find a more elegant solution. Thanks for considering it. Steve

#6	AlbrechtS 03:35 Aug 16, 2015

Hi Steve, thanks for your reply confirming my guesses about how you build your apps with FLTK. This will hopefully help finding a better solution. I'll do some tests and try to find another way after writing this post. That said... I have to admit that the way you (and maybe others) build FLTK was not considered in my approach, and the consequence that it broke your build was not intended. I wrote that already. I'm not trying to justify my solution, but I need to comment on some of your statements. > Fair enough, but your solution does overwrite abi-version.h No, it doesn't. That's the reason why FL/abi-version.h is NOT in svn. As I wrote before, configure unfortunately generates this file in the source tree (because configure only works with in-source builds of FLTK), and hence it *would* overwrite a versioned file if FL/abi-version.h were in the source tree. > which is now part of the source code (since it won't build without it). This is not a valid conclusion. There are other files generated by the build process with configure and CMake that are also necessary to build the lib (for instance config.h). Generating necessary build files depending on configuration options or platform is standard for configure- and CMake-based builds. The only exceptions are our bundled IDE files, which is why we have pre-configured (versioned) '<IDE>/config.h' and now also '<IDE>/FL/abi-version.h' files in svn. That's the _compromise_ I mentioned in my previous post: we have generated (non-versioned) files for the two major build systems (configure and CMake) but we need to provide pre-generated (versioned) files for the bundled IDE files. > Even more, for IDE developers this file is versioned and has to be > manually edited, so for IDE developers nothing has really changed Yep. Exactly that was the intention. We could only improve the build process for configure and CMake, but not for IDE builds. Previously /all/ users had to edit an essential, versioned build file (FL/Enumerations.H), now only IDE users need to edit a versioned file if they want to change the ABI version. That's an improvement for the entire FLTK system, although this does not help IDE users. > (except that all of their projects broke of course :) ). Okay, see above. Not intended. Let's see how we can improve that.. > 3) developers need to be able to use different configurations to > test all ABI versions for better quality control. > > Very true, but that does not justify the approach taken. You could > do this with the previous approach too. No, we couldn't - at least only in a far less comfortable way. With CMake's configuration and out-of-source builds it is possible to build - at the same time - in parallel, differently configured build trees - from the same source tree. The big advantage is that you can test your changes before committing anything with different build options (particularly ABI versions, but others as well). You don't need to have (many) different (svn or git) working copies and move your patches around to test different ABI versions, which would be error-prone and less comfortable. What does it mean to "justify" a change in the build system? I believe that everything that makes the development easier for the core devs and does not have negative impact on users would justify such an improvement. If it had worked as intended you (and most of the IDE users) probably wouldn't even have noticed it. That was the plan. Sorry for the inconveniencies.

#7	AlbrechtS 06:02 Oct 18, 2015

I raised the priority to "High" (4) to make sure we find a better solution before the release of FLTK 1.3.4. I'm working on it, but please don't hold your breath... My plan is to remove all abi-version.h files from the IDE folders again and add a pre-configured FL/abi-version.h file in the release and snapshot tarballs. This way only IDE users using svn would have to copy a template file manually, whereas the snapshot and release tarballs would have one included in the right place w/o having a versioned file in svn which would be problematic for configure-based builds, as mentioned above.

#8	AlbrechtS 06:17 Jan 19, 2016

Hi Steve, sorry for the long delay, I was too busy with other work, and MS IDE stuff is not my daily work. But eventually I made progress... I found a hopefully better solution by creating a "Pre-Build Event" in the IDE project configurations. This Pre-Build Event copies a (new) template file <fltk-root>/abi-version.ide (with detailed instructions how to edit it) to FL/abi-version.h. In my tests I could successfully build the IDE projects ide/VisualC2008 and ide/VisualC2010. Since the file FL/abi-version.h exists after the build your projects should now work w/o any modifications. Furthermore users that need to configure another ABI version with VS IDE projects can do so, although they still need to edit a versioned file (abi-version.ide). Unfortunately you can't edit FL/abi-version.h because it would be overwritten by the next build process. This has been committed in svn r11010. I'd appreciate if you could try this solution and confirm that it solves your needs so we can be sure not to break your and other users' existing VS projects anymore. Please use a fresh checkout or make sure that the 'old' abi-version.h files in the IDE folders are deleted, as well as FL/abi-version.h (which you added yourself). The clean the FLTK IDE solution or "Rebuild" the complete project. Thanks in advance. Note: The commit in svn r11010 only modifies VisualC2008 and VisualC2010 IDE files. VisualC6 and potentially Xcode4 are still to be fixed.

#9	AlbrechtS 14:00 Jan 20, 2016

FTR: a similar solution was committed for the bundled Xcode IDE project in svn r 11011, 11014, and finally r 11015 (cleanup). Thanks to Manolo. The only missing part is now the VisualC6 project.

#10	greg.ercolano 17:39 Jan 23, 2016

OK, I've fixed VisualC6 in r11041. Using VC6 (old!) I added abi-version.h as a file it's dependent on, and gave it a custom build command using 'copy', e.g. copy /Y ..\..\abi-version.ide ..\..\FL\abi-version.h I then loaded up VS7, deleted FL\abi-version.h, and built FLTK and I can see the messages at the top of the build saying it copied the file, and runs OK. Ditto for both Release and Debug builds. Albrecht: if this is all you were waiting for to close this STR, feel free to do so.

#11	greg.ercolano 18:03 Jan 23, 2016

Oh, and here's the 'proof'; relevant parts of the VS7 build log; top few lines, middle few lines showing the copy operation (see "<-- NEW"), and the last few lines showing the successful build of the entire FLTK project. ________________________________________________________________________________ __ ------ Build started: Project: fltk_zlib, Configuration: Release Win32 ------ Compiling... zutil.c uncompr.c [..snip..] ------ Build started: Project: fltk, Configuration: Release Win32 ------ Creating FL\abi-version.h from abi-version.ide <-- NEW 1 file(s) copied. <-- NEW Compiling... vsnprintf.c screen_xywh.cxx [..snip..] ---------------------- Done ---------------------- Build: 84 succeeded, 0 failed, 0 skipped ________________________________________________________________________________ __

#12	AlbrechtS 16:39 Jan 25, 2016

Thanks, Greg, for updating the VisualC6 project files. Steve, does this (current svn) now work for you? Please confirm, so that we can close this STR.

#13	AlbrechtS 05:54 Jan 30, 2016

Fixed in Subversion repository. The final fixes were in svn r 11041, 11042, and 11045. Closing this STR now.