Re: compiling euphoria 4.0

new topic     » goto parent     » topic index » view thread      » older message » newer message
Jim C. Brown said...
Shawn Pringle said...
No One said...

Thats my point. revget.ex should be detecting the right value automatically now.

But don't you see that doesn't matter? Make will look at rev.e and see if it needs to be updated because it is correctly listed as an indirect dependency of the interpreter but since there are no dependencies revget.ex never gets called by make.

To be annoyingly pendantic, that is technically a separate issue from what was originally discussed.

Shawn Pringle said...

You need a dependency:

 
rev.e : .\$(SVNDIR)\entries 
	$(EX) revget.ex 

I was trying to build on a non-Microsoft file system. The value .svn is also svn~1 on any Microsoft file system but on my third party driver it doesn't do that.

The reason I did not want to add .svn\entries or svn~1\entries as a dependency was because anything in a .svn dir is subject to change. It is possible for svn 1.5 to get rid of the entries file for working copies and replace it with something completely different. More realistically, 1.5 might add a new field (such as a time for when 'svn update' was last run by the user) which could cause the timestamp on the entries file to be updated even though the svn revision hadn't changed.

I want to keep all of that logic (the svn specific stuff) in revget.ex itself. Less breakage that way when things finally break.

I finally thought of a way to fix this for the watcom makefile. Add a couple of dependencies to 'all' (and/or various other targets): rev_check, which is always called and deletes a file called rev.txt, and rev.txt, which calls revget.ex and then creates an empty file called rev.txt

This is pretty hacked, though. Maybe it is possible to get away with just adding svn_rev as a direct dependency of all.

Yes, replacing all references to rev.e in dependecy lists with svn_rev appears to fix this. Nice and easy.

I'll commit as soon as SF.net allows it again, but Jeremy has some important changes so there may be a conflict. :(

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu