Another dropbox framework import error

I’ve had to rebuild the dropbox framework and I’m having more issues importing again (previous one was Dropbox Framework). This time it gets to

            Message Loading include info for fx: /Users/Jeremy/Downloads/RemObjects Elements/Toffee SDKs/iOS 12.1 Simulator/WebKit.fx
            Parsing (root) file: ObjectiveDropboxOfficial/ObjectiveDropboxOfficial.h
            Error  (0:0 pp: 0): Unknown member in class: @class DBRpcTask

(then there’s lots of similar for all other classes).
This is with latest, though I’ve tried a few older element builds as well. I’ve also tried it with the original commit from the dropbox git that I used and also the latest. All is the same.

Incidentally, I notice that the framework import always uses the external compiler rather than the one with Fire - is that by design?

Hmm, not really. what makes you say it does? FX Import embedded in Fire should run the HeaderImporter.exe that’s inside Fire…

Just that the lines “Message Loading include info for fx:” all refer to my external compiler location. I see in the log that header importer is using the one inside Fire though.

Also found this in the log:
function runHeaderImporterForLibrary([object Object], --fxpaths "/Users/Jeremy/Downloads/RemObjects Elem…) {

Hmm. but you have the internal compiler set to be active? lemma check the code…

        script.AppendLine(String.Format("var fxBaseFolder = \"{0}\";", coalesce(ToffeePaths.Instance.SdkFolder, ToffeePlatform.internalToffeeSdkFolder)));
        script.AppendLine(String.Format("var developerFolder = \"{0}\";", ToffeePaths.Instance.LocalXcodeDeveloperFolder()));

yup. I pass the external fx folder, if configured, else the internal one (regardless of what compiler Fire is set to use). you believe this is problematic? it’s legitimate to override the external fx folder w/o using the external compiler, via Preferences, after all…

Your call I guess, the only reason I noticed was that the log showed a really odd folder name since the
last time I downloaded the external one was from firehose to test a fix for something and once Fire caught up with it, I turned off the external compiler and assume it’s not using it at all. So, I downloaded the latest (stable and beta) and tested with that.

I have the same error in another framework I need to import into another project.

Do you have a sample of something that shows this? It’s hard to guess from the error.

Can you just grab the dropbox SDK from git (see Dropbox Framework) as I think that’s what you did last time?

ah yes. got it now. Completely forgot about that bug.

Could it be that it emitted the fx just fine but printed errors?
I just fixed those errors but they didn’t seem fatal. Thanks for the report.

Well, the fx was generated, but no .pas etc, and so when I try to use it, it doesn’t know any of the classes. I see the commit, so I’ll try it shortly and let you know.
Thanks

1 Like

Could be marcs’ train wrapper captured the error and thought it failed. It’s just doing headerimporter codegen file.fx file.pas

Right, ta, I’ll try that first actually as that may give marc something else to look for, for the errors.

I just tried d91c627 but I’m still getting the same error. I’ll wait for the next beta, but here’s the full output in case you want to look.
log.txt (50.9 KB)

framework import won’t generate a pas, just a fx.

Ah. Can you remind me of the step to do that then, as I don’t recall doing it myself. Is there a train script example or something? I’ve not had chance to look at calling header importer passing the parameters carlo suggested. I must spend some time looking at train actually.

just run “headerimporter codedgen your.fx oxygene

OK, I’m pretty sure I’ve never created the codegen files previously (there were swift etc ones before and I wouldn’t need those anyway), but that did work, but then what are those files for? I never had them in my project. Anyhow, I have now ignored that, gone back to the beginning and fxgened the framework with d91c627 and all is now good and working.