1. ATTN: Translator Change in SVN 2015
- Posted by jeremy (admin) May 01, 2009
- 901 views
The translator has changed from generating an emake/emake.bat file by default to compiling by default. If you want to use the old emake/emake.bat file you need to specify -emake on the command line. Note, there is also new options added a hundred revisions ago or so:
- -makefile: Generates a partial prgname.mak file that can be included into a larger Makefile project
- -makefile-full: Generates an entire Makefile named prgname.mak that can be used directly
- -cmakefile: Generates a prgname.cmake file that can be included into a larger CMake project
We now have two new ways of building things as well:
- -emake: Generate the old emake/emake.bat file
- no option causes euc to build the translated code directly at the same time of translation
If you have automated systems setup already for 4.0, you will possibly need to modify your code because the emake files are no longer generated by default, nor required to compile by default.
Just a heads up.
Jeremy
2. Re: ATTN: Translator Change in SVN 2015
- Posted by bernie May 01, 2009
- 773 views
You keep posting build process changes on the forum.
Could you please just place one reference document in one place
that describes each step of the build so it is less confusing.
Thank You.
3. Re: ATTN: Translator Change in SVN 2015
- Posted by jeremy (admin) May 01, 2009
- 780 views
You keep posting build process changes on the forum.
Could you please just place one reference document in one place
that describes each step of the build so it is less confusing.
Thank You.
Each have been different changes. All will be in the docs but I am asking specifically if a few people could test the new processes so that we have as few surprises in beta stages as possible.
Jeremy
4. Re: ATTN: Translator Change in SVN 2015
- Posted by georgeorr May 01, 2009
- 802 views
Jeremy - I have tested this change (using SVN 2020) on both Linux and Windows Vista with no problems. I do still forget to use the winall option for wmake, so I get DOS errors. I'll learn eventually!
One other thing I have noticed is that while declaring EUINC to be the \include directory on Linux seems to allow euphoria to find include files in the \include\std and \include\euphoria directories, I have to add these subdirectories to the EUINC environmental variable when I use Vista. Is this normal, or did I miss a configuration step somewhere?
Thanks. It's really hard keeping up with the development team! Great effort.
George
You keep posting build process changes on the forum.
Could you please just place one reference document in one place
that describes each step of the build so it is less confusing.
Thank You.
Each have been different changes. All will be in the docs but I am asking specifically if a few people could test the new processes so that we have as few surprises in beta stages as possible.
Jeremy
5. Re: ATTN: Translator Change in SVN 2015
- Posted by jeremy (admin) May 01, 2009
- 817 views
Jeremy - I have tested this change (using SVN 2020) on both Linux and Windows Vista with no problems. I do still forget to use the winall option for wmake, so I get DOS errors. I'll learn eventually!
Hm, you should be able to build the dos stuff as well. What are the DOS errors?
One other thing I have noticed is that while declaring EUINC to be the \include directory on Linux seems to allow euphoria to find include files in the \include\std and \include\euphoria directories, I have to add these subdirectories to the EUINC environmental variable when I use Vista. Is this normal, or did I miss a configuration step somewhere?
Thanks. It's really hard keeping up with the development team! Great effort.
You should only have to set EUDIR, EUINC shouldn't need to be set if you don't do exotic things. Then when including things you do:
include std/sequence.e
Jeremy
6. Re: ATTN: Translator Change in SVN 2015
- Posted by georgeorr May 01, 2009
- 800 views
- Last edited May 02, 2009
Jeremy -
I am running the 64-bit version of Vista. The error says that le23p.exe cannot start or run due to incompatibility with 64-bit versions of Windows. I really don't need or use DOS programs anyway. In fact, I find euphoria a much better fit with Linux and am really only using the Vista versions to test out EU4.0. I guess that could change if I get into the GUI programming frameworks a little deeper.
On the EUINC note, I prefer to use EUINC and point at all the include directories since I can't always remember where each include file is located! Old age, I guess. My EUINC on Linux actually included the std and euphoria folders, so my earlier comment really should be ignored. I just forgot I had done this!
I think there was a problem with std\include versus std/include on Windows when I tried your suggestion, but I'm not sure I didn't do something else wrong. Using EUINC I use the same code on both boxes with no changes.
Thanks again!
George
Jeremy - I have tested this change (using SVN 2020) on both Linux and Windows Vista with no problems. I do still forget to use the winall option for wmake, so I get DOS errors. I'll learn eventually!
Hm, you should be able to build the dos stuff as well. What are the DOS errors?
One other thing I have noticed is that while declaring EUINC to be the \include directory on Linux seems to allow euphoria to find include files in the \include\std and \include\euphoria directories, I have to add these subdirectories to the EUINC environmental variable when I use Vista. Is this normal, or did I miss a configuration step somewhere?
Thanks. It's really hard keeping up with the development team! Great effort.
You should only have to set EUDIR, EUINC shouldn't need to be set if you don't do exotic things. Then when including things you do:
include std/sequence.e
Jeremy
7. Re: ATTN: Translator Change in SVN 2015
- Posted by jeremy (admin) May 01, 2009
- 816 views
- Last edited May 02, 2009
I am running the 64-bit version of Vista. The error says that le23p.exe cannot start or run due to incompatibility with 64-bit versions of Windows. I really don't need or use DOS programs anyway.
OK. I would suppose a 64bit OS would cause problems with the ancient DOS stuff. I'm with you on not needing/wanting DOS stuff 
Jeremy
