OpenEuphoria

2. Re: svn problem with pcre?

• Posted by jeremy (admin) Apr 27, 2009
• 916 views

George,

This is a problem with the Makefile. We are looking to greatly simplify the makefile or move to a different build system altogether because it's complex and only one person knows how it actually works well enough to fix it. We are waiting on it to be fixed. It was committed to SVN incorrectly.

Jeremy

4. Re: svn problem with pcre?

• Posted by jeremy (admin) Apr 27, 2009
• 907 views

That's why we are exploring a new build system. Building Euphoria is more complex than the average program due to the generated sources and the fact that the sources generated change all the time. This has caused many things to get complex quickly.

Our makefile was simple a while ago, however it was very problematic. As you add a section of code to the interpreter, the makefile would no longer compile things. We would then have to edit the makefile, update the generated file list, then recompile and test our changes. Then the makefile was made much smarter and we no longer had to do that and everyone was happy. However, now when we want to change the makefile, it's quite complex and understood by only one person. So, the new makefile is less troublesome but very complex. That's how we got to where we are.

There are other options out there but many of the build systems have had problems working with our generator because it generates an unknown list of files. We have worked with Watcom Make, GNU Make, CMake and Jam thus far. On all of them we have had to go to the more advanced/complex methods to make things work. The CMake file is the simpliest so far, but it has it's problems as well as much as I like it.

I hope we can get the build tool chosen and working well before we move to beta.

Jeremy

6. Re: svn problem with pcre?

• Posted by jeremy (admin) Apr 27, 2009
• 885 views
• Last edited Apr 28, 2009

I guess I jumped ahead thinking of the problem then building pcre once you get past the svn up. Opps.

Jeremy

8. Re: svn problem with pcre?

• Posted by jeremy (admin) Apr 27, 2009
• 954 views
• Last edited Apr 28, 2009

Jim just added the building of eutest to the Watcom makefile only. It's a total of 33 lines. We have to translate this to work with GNU Make, then add something similar (but different) to the Unix Makefile so eutest can be built on Unix as well during a normal build install of a source package. Also, the below doesn't include any install or clean targets.

$(BUILDDIR)\eutest.exe: $(BUILDDIR)\eutestdr\main-.c $(BUILDDIR)\eutestdr.wat $(BUILDDIR)\eu.lib $(BUILDDIR)\eutestdr 
	@%create $(BUILDDIR)\eutestdr\eutestdr.lbc 
	@%append $(BUILDDIR)\eutestdr\eutestdr.lbc option quiet 
	@%append $(BUILDDIR)\eutestdr\eutestdr.lbc option caseexact 
	@%append $(BUILDDIR)\eutestdr\eutestdr.lbc library ws2_32 
	@for %i in ($(EUTEST_OBJECTS)) do @%append $(BUILDDIR)\eutestdr\eutest.lbc file %i 
	wlink  $(DEBUGLINK) SYS nt op maxe=25 op q op symf op el @$(BUILDDIR)\eutestdr\eutestdr.lbc name $(BUILDDIR)\eutest.exe 
 
$(BUILDDIR)\eutestdr.wat : $(BUILDDIR)\eutestdr\main-.c 
	@if exist $(BUILDDIR)\objtmp rmdir /Q /S $(BUILDDIR)\objtmp 
	@mkdir $(BUILDDIR)\objtmp 
	@copy $(BUILDDIR)\eutestdr\*.c $(BUILDDIR)\objtmp 
	@cd $(BUILDDIR)\objtmp 
	ren *.c *.obj 
	%create eutestdr.wat 
	%append eutestdr.wat $(EU_NAME_OBJECT) = &   
	for %i in (*.obj) do @%append eutestdr.wat $(BUILDDIR)\eutestdr\%i &  
	%append eutestdr.wat     
	del *.obj 
	cd $(TRUNKDIR)\source 
	move $(BUILDDIR)\objtmp\eutestdr.wat $(BUILDDIR) 
	rmdir $(BUILDDIR)\objtmp 
 
 
$(BUILDDIR)\eutestdr\main-.c : $(TRUNKDIR)\source\eutest.ex $(BUILDDIR)\eutestdr 
	-$(RM) $(BUILDDIR)\eutestdr\*.* 
	cd  $(BUILDDIR)\eutestdr 
	$(EXE) $(INCDIR) $(EUDEBUG) $(TRUNKDIR)\source\ec.ex -wat -plat $(OS) $(RELEASE_FLAG) $(MANAGED_FLAG) $(DOSEUBIN) $(INCDIR) $(TRUNKDIR)\source\eutest.ex 
	cd $(TRUNKDIR)\source 
 
$(BUILDDIR)\eutestdr : 
	mkdir $(BUILDDIR)\eutestdr 
 

In cmake, for example, here is the building what was added to build eutest:

EUC( eutest.ex eutest ) 
 
ADD_EXECUTABLE( eutest ${EXECUTABLE_FLAG} ${EUTEST_SOURCES} ) 
TARGET_LINK_LIBRARIES( eutest eu_back ${EXTRA_LIBS} ) 
IF( LINK_FLAGS ) 
  SET_TARGET_PROPERTIES( eutest PROPERTIES LINK_FLAGS ${LINK_FLAGS} ) 
ENDIF() 

The above works on Watcom and GNU Make, plus our experiemental MSVC build. I have not yet optimized it either. Really, a few of those lines should move to the EUC call.

Jeremy

10. Re: svn problem with pcre?

• Posted by jeremy (admin) Apr 28, 2009
• 967 views

I have not spent time with it recently because of the problem in needing to pre-translate the code, which I didn't like. I was just using the simplicity of CMake as an example.

I am not sure of the answer, but I do know it's quite a drag having to maintain the two build files, and then if in 4.1 we release a MSVC version that's a 3rd makefile that everyone has to learn the syntax of and maintain when making any changes.

Jeremy

12. Re: svn problem with pcre?

• Posted by jeremy (admin) Apr 28, 2009
• 901 views

Well, the problem with that approach is the need to transfer all sorts of possible configuration flags to the child process. For instance, did the user customize the CFLAGS working on finding the best optimization flags? Or do they have some new platform they are porting to so they added a flag like -DWEIRD_OS... All of those need to be passed on to the child.

Jeremy

14. Re: svn problem with pcre?

• Posted by jimcbrown (admin) Apr 28, 2009
• 880 views

Actually, that should be the most trivial part....