It looks like you're new here. If you want to get involved, click one of these buttons!
I beg pardon for the very newbie question, but not being so much expert in c++ I was wondering if there is any problem to use the microsoft compiler in windows or if instead I should use clang.
Hi @Daniele Niero
On Windows we rely on visual studio 2013 to do the builds.
Technical Product Manager
Fabric Software Inc.
So would visual studio 2017 community work with kludge?
On low end DSL I'd hate to download something that big as a failed experiment.
Of course it would have plenty of other uses, but still
I was able to get VS2017 (community edition) to compile the test projects given in Fabric's documentation. Unfortunately the extensions created only crashed Fabric and I had already spent too many hours figuring all the missing library and include elements out that I finally decided it wasn't ready for prime time yet.
See below: That is probably due to my dumbness, so you will very likely be able to get it to work!
You need to first install C/C++ "Workloads", then manually add C++/CLI Support in VS Installer, also "standard library modules" (sorry, my stupid Microsoft environment doesn't get that I want English UI, it always pops back to German, so I have to guess what the English wording might be). I also installed VC++ Toolsets and Universal CRT SDK (not sure this is needed, but I remember having some includes missing that were CRT related).
I also added MFC/ATL and Windows 10 SDK for Desktop C++ and Windows Universal C-Runtime).
You can "get there" by observing what includes are missing and checking which package those are in.
Like I said - I ended up with a "working" compiler setup that creates crashing extensions, so I am not a happy camper at all (I had two projects where I needed to have my own C++ stuff included - I wanted to do it with Fabric in order to "convince" a client to buy a commercial license of Fabric - since I couldn't get it working, I ended up with making all the money myself and no Fabric license for the client).
BUT that is probably due to me being stupid. I prefer stuff that "just works" (that's why I usually love to work with Fabric) and hate, with all my heart, the "Linux way of doing things" (guess working, trial and error, shell scripts to do a simple "1+1" calculation, installation of hundreds of arbitrary tools that don't cooperate well, manually diff-updating everything for days and days - you get the picture).
Marc Albrecht - marc-albrecht.de - does things.
Ah yeah, I feel your pain.
My C++ coding experience is very modest, at best, and I haven't done much in the last several years so my knowledge is bit rusty. Hopefully someone with more experience can correct or confirm my guess work.
Per Borja's reply that they use VS2013 for their builds and the fact that the FE docs state "Note: Windows requires installing Visual Studio 2013 redistributable if it is not already in the system." ( Noticed that after I asked my question, Doh! ) I believe the use of kludge most likely requires the VC++ 2013 (v120) toolset, .NET Framework 4.5.1, and possibly the Windows7.1SDK for both the compiling of the library from source and the generating an FE extension from it via kludge.
Also since the tutorials use scons to run the builds you'd probably need your Windows PATH and/or visual studio to target the VC++ 2013 (v120) toolset/.NET Framework 4.5.1 (and maybe the Windows7.1SDK) as the default environment.
The real sticking point here with VS 2017 Community is that neither the VC++ 2013 (v120) toolset nor the Windows7.1SDK appear to be offered as optional components in the C++ workload, so a user would have to download and add them to their available targets manually. (Though I suppose they might be in the core feature set of the workload.) At least they're still available as separate downloads.
VC++ (v120) 2013 toolset (I think)
Windows7.1SDK & .NET Framework 4
Linux compiling in general, is entirely different kettle of fish, but in some ways much easier to setup. Though for kludge stuff you have to use a CentOS 6 distribution. Which in terms of 'just working out of the box' is OK, but far from perfect.
you may be right there and it's definitely worth a shot. But, to be honest, Windows 7 is not an actual OS and I don't intend to develop for outdated OS. None of my client's systems are running Windows 7 actually - I do know that you can redistribute old library material (like NET Frameworks), but this just doesn't make sense to me, as it simply adds another potential breaking point (piling up various runtime environments).
I have to develop MS Office tools for some of my clients. It is an unbelievable pain how many outdated DLLs you have to link to some almost trivial code just to have that stuff running smoothly in the background. I just don't need more of that :-)
Well, that's weird. I edited some grammar in my second comment and it went away for moderation, hope it comes back, or this whole conversation becomes a giant non-sequitur
If I recall correctly targeting the Windows7.1SDK isn't so much about targeting Windows 7 specifically, but targeting the widest range of compatibility. Which I grant you really seems a bit counter-intuitive, but it might be helpful with a lot of missing dll errors.
Mass market commercial applications with installers add missing toolset redistributables they require (2012, 2013, 2015, etc) all the time. They just generally don't show us that particular sausage being made.
I don't envy you writing/maintaining code when clients are involved. I can only imagine how hellish that could get.
just to avoid this going non sequitur: You are correct, of course, in that many software packages "spilling their goods all over the place". That is not to say that I like that (having over a dozen MS -insert-year- NET libraries installed).
On Topic: If I somehow find the time, I'll do another test run with older libraries instead of those I can reach from the VS Installer and update here. I am pretty sure that compiling FE extensions with VS2017 is possible - just not "right out of the box" and probably not "painfree". What loops one has to jump through when installing a solution on a second system then remains to be seen.
I could not get VS2017 to compile Fabric extensions that do not crash. So I stepped back bit by bit and finally decided to give another approach a chance: There is a reduced-size "command line built tools package" VS2015 - I installed this package (on top of my existing 2017). With THIS Kludge works "out of the box" (i.e. you start a VS2015 build tools command line prompt, read in Fabric's environment.bat from there and, having Kludge installed according to the docs, you can start rocking).
Here's the link to the VS2015 build tools: http://landinghub.visualstudio.com/visual-cpp-build-tools
I hope this is of any help to anyone!
After a little hunting, found an info page: https://blogs.msdn.microsoft.com/vcblog/2015/11/02/announcing-visual-c-build-tools-2015-standalone-c-tools-for-build-environments/
By default, it looks like, other than the v2015 toolset, the main component is the Windows SDK 8.1. I'm curious did you do a default or custom download?
FYI to anyone interested in download size; it's roughly 4GB. (That's about 12 and half hours on low end DSL, which while not trivia, is doable)
the 2015 build tools definitely weren't 4GB download for. I am Germany-based, meaning, I have some of the worst internet connections dreamable, a 4GB download I would have postponed ... so my guess is that the build tool downloader/installer (that you download first) recognized some of the stuff that I already had installed for VS 2017. Which makes it hard to find out what you actually need.
I did a fully automatic install with the build tool and it worked right away, scons wasn't complaining any longer and the resulting compile did not crash Fabric.
I read somewhere else that scons might need Windows 7 SDK (as opposed to 8.1), so I installed the Windows XP(!!!) SDK (in VS 2017), which is said to include Windows 7 SDK (somebody send a bottle of sanity over to Microsoft, please). That did not change anything in the previous mal-behavior of scons/VS2017 for me, so my guess is that you do need some of the older SDK (for the standard libs includes, obviously) but it probably doesn't matter much which one you choose.
It seems more likely that scons is the big problem here and that it just doesn't work well together with current versions of VS2017. You probably can "hack" it (adjust environment variables, copy includes somewhere else, whatsnot - I did get it to do something ), but it really isn't worth the hassle, in my eyes, because a "hacked" development environment isn't durable. Imagine having to go back to a hacked environment 20 years after you developed something in there - which is a situation I run into frequently - that's just bonkers
That 4GB amount came from the web page I linked to. Specifically from image captures of the installer GUI. Looking at it closer that may be the amount of disk space required by setup, not download size. If so, good news
With the start of the workweek maybe we'll get some definitive feedback on this stuff from the Fabric team.
Appreciate all the effort on your part, thanks a lot.
The supported toolchains for Fabric are Visual Studio 2013 (we build against this version) and 2015. You should be able to download visual studio 2015 community from https://msdn.microsoft.com/en-us/visual-studio-community-vs.aspx
1) You get to work early.
2) Do you only need Windows 8.1 SDK for kludge to work properly? I'd like to keep the disk footprint and download size as small as possible. ( Heck I've even found a Build Tools 2013 that's only 17.6 MB, but that seems to good to be true. )
I am not sure which specific packages are necessary, let me check with the dev team to see if they are aware of the bare minimum build tool size requirements
I am sorry but the team is not aware if the build tool would be simplified for using kludge. We just use the standard visual studio installation.
Going on Marc's experience and some other info tracked down via search late last night (The default C++ Build Tools 2015 install appears to be a 26 MB download!) testing shouldn't be a huge commitment of time or resources.
I have to do some other stuff first, and might not get to it today, but I'll post the results after I give it a shot.
Y'know how I said 17.6MB seemed to good to be true and then found a Build Tools 2015 that was only 28mb and decided it was true? Well, yeah, no, it was too good to be true
The 28MB download installed out to around 147MB, but doesn't have anywhere near what's needed to be a working tool chain. I think it's designed to provide a few missing tools in certain very specific scenarios.
C++ Build Tools 2015 is what's needed for a working tool chain and it's install will take roughly 4GB of disk space, using the default settings. Given how much the 28MB file expanded on install I was hopeful the download would be a lot less than 4GB, and that turned out to be correct. The download took roughly 2.5 hours on low end DSL(768Kbps) so I figure it was around 825MB. It looks like a good rule of thumb for VS downloads may be 20% of install size.
Initially could not get the 1st kludge tutorial to work, errors during the scons build, but I finally got it working. Here's what I did to generate the .dll and .lib files (Correct? Incorrect?)
cl /LD Tutorial.cpp // creates the .dll and .obj
lib /OUT:Tutorial.lib Tutorial.obj // creates the .lib
I did do a repair of the C++BT2015 install before I got it working but I'm not sure if that's what fixed things.
in theory you should be able to use "scons" (that's the "make" tool Kludge wants to use) - the problems I have had, including the crashing compilations, seemed all to be scons-related.
In order for scons to work correctly, i.e. find includes and dlls, you should start your session with the VS command line environment, which should set up all required ENV vars, then from there include (run) the environment.bat from your Fabric installation, which should add the required path elements. Then, again in theory, scons should work from the created .scoptions file. So you should not need to run compiler (cl) and lib-linker manually.
I hope this is of any help!
©Copyright 2017 Fabric Software Inc. All rights reserved. | Privacy