Re: "Easy" way to remove MFC-dependence AND port to Linux?!
 

But what about compiling while including special additional libraries? (Like the gnulib you mentioned above...)

Re: "Easy" way to remove MFC-dependence AND port to Linux?!
 

It's all about how the code is written. If one wanted to include gnulib without taking out MFCs, it would be twice the code. Hmm, and I hadn't thought of this until right now, but MFCs only work on Windows and in fact it's illegal to use them on other systems (per MS license) not to mention that they won't work.

As I think about it a little more carefully, I have no idea how a program reacts when you have two calls for the same thing (one for each library). I imagine you would need to put in code at the beginning saying something like "if gnulib present, ignore MFC" and vice versa I think it will be easier to replace MFCs in chunks - but I don't know how big of chunks - to check it out and see if it's working.

This is really stretching my programming knowledge. :)

Re: "Easy" way to remove MFC-dependence AND port to Linux?!
 

Well, definitely, I think ultimately removing MFC would be the way to go.

I'm just not sure how to compile anything with added libraries (just leave a copy of the libraries in a folder nearby or something like that?).

It does seem a good idea to replace MFC in chunks, so that we can actually see what is going wrong as we find it... :D That would probably require working on Windows with MFC, though, until it is eradicated...

Re: "Easy" way to remove MFC-dependence AND port to Linux?!
 

Finding libraries when compiling is easy. :) Either the library is compiled right along with everything else for use, or it is in a location that is known to the code (the code actually contains the path info).

The problem with doing it in chuncks is that for a while (until it's done) the source code will be a lot bigger and more resources will be needed for running the compiled programs.

Re: "Easy" way to remove MFC-dependence AND port to Linux?!
 

Hmm - good point!

If DC is done in objects (or some other neat way of division), might be doable, 1 object at a time...

But anyway, I wouldn't be able to try to do the MFC thing myself, I guess, since I can't compile on Windows - unless, of course, I wanted to try doing the WHOLE THING before compiling it... (a definitely recipe for failure!)

Re: "Easy" way to remove MFC-dependence AND port to Linux?!
 

I wrote a reply, hit send and my browser crashed. :( I forgot what I said in it, but let's just pretend that is was very witty (not like I normally write at all). :)

If you were to contact someone who knew about this - LurchBrick, Tarlanon, Paul, CocoaSpud - maybe it's the case that each object can be checked independent of the whole project. I do know (what follows is obvious) that the editor, engine, gpdl and cdx parts can be compiled separately...it may be that subsections can as well.

Re: "Easy" way to remove MFC-dependence AND port to Linux?!
 

Hmm - that wasn't obvious to me! :D (Will have to try this one of these days... but I may lose it and lapse into drawing pictures again instead)

Re: "Easy" way to remove MFC-dependence AND port to Linux?!
 

You should take a look at the code SourceForge. It'll give you a good idea of what lays ahead of the linux conversion team.

In the source, you'll see that it breaks down into four separate areas (the ones I outlined in the earlier post).

Re: "Easy" way to remove MFC-dependence AND port to Linux?!
 

Unfortunately this can't be done separately. Everything, objects, drawing code, etc uses MFC and CDX as a base so you can't just update one part of the code to run on some other library as it has to interact with MFC.

Hence why I still believe that starting over from scratch is the simplest way to go forward.

Re: "Easy" way to remove MFC-dependence AND port to Linux?!
 

Yay! Finally someone who is a coder. :) I knew if I started using names, someone had to answer.

I had suspected this. Oh well, it doesn't it can't be done, just like you say LB, it will probably just be easier to to start anew, except for maybe CocoaSpud b/c of his great familiarity with the code (he had said that it was something he wanted to do, but the task seemed too big).

As I've said before LurchBrick, anything I can do to help... :D:D:D