1. VER 4.0 build error

While building SVN1488 on XP I get the following error.
Has there been a change in configure or makefile.wat ??

I reverted back to SVN1486 but I get the same error.

I see a lot of compiling going on with the PRE stuff has that
got anything to do with the revget.ex command line ???

The current SVN I am using is SVN1431 so I don't want to spend
hours of compiling to narrow it down.

        1 file(s) copied. 
        1 file(s) copied. 
        1 file(s) copied. 
        1 file(s) copied. 
        1 file(s) copied. 
        1 file(s) copied. 
        1 file(s) copied. 
        1 file(s) copied. 
Open Watcom Make Version 1.8 
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved. 
Source code is available under the Sybase Open Watcom Public License. 
See http://www.openwatcom.org/ for details. 
------- ALL ----------- 
        wmake -h -f makefile.wat winall DEBUG= MANAGED_MEM= CONFIG=config.wat 
------- WINALL ----------- 
wmake -h -f makefile.wat interpreter DEBUG= MANAGED_MEM= CONFIG=config.wat 
wmake -h -f makefile.wat E:\eu_master\source\intobj\main-.c EX=e:\eu_master\bin\ 
exwc.exe EU_TARGET=int. OBJDIR=intobj DEBUG= MANAGED_MEM= CONFIG=config.wat DEBU 
G= MANAGED_MEM= 
mkdir E:\eu_master\source\intobj 
mkdir E:\eu_master\source\intobj\back 
e:\eu_master\bin\exwc.exe -i ..\include revget.ex 
Incorrect usage. 
Error(E42): Last command making (rev.e) returned a bad status 
Should this file be deleted [Yes/No] ? 

new topic     » topic index » view message » categorize

2. Re: VER 4.0 build error

bernie said...

While building SVN1488 on XP I get the following error.
Has there been a change in configure or makefile.wat ??

I reverted back to SVN1486 but I get the same error.

I see a lot of compiling going on with the PRE stuff has that
got anything to do with the revget.ex command line ???

The current SVN I am using is SVN1431 so I don't want to spend
hours of compiling to narrow it down.

        1 file(s) copied. 
        1 file(s) copied. 
        1 file(s) copied. 
        1 file(s) copied. 
        1 file(s) copied. 
        1 file(s) copied. 
        1 file(s) copied. 
        1 file(s) copied. 
Open Watcom Make Version 1.8 
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved. 
Source code is available under the Sybase Open Watcom Public License. 
See http://www.openwatcom.org/ for details. 
------- ALL ----------- 
        wmake -h -f makefile.wat winall DEBUG= MANAGED_MEM= CONFIG=config.wat 
------- WINALL ----------- 
wmake -h -f makefile.wat interpreter DEBUG= MANAGED_MEM= CONFIG=config.wat 
wmake -h -f makefile.wat E:\eu_master\source\intobj\main-.c EX=e:\eu_master\bin\ 
exwc.exe EU_TARGET=int. OBJDIR=intobj DEBUG= MANAGED_MEM= CONFIG=config.wat DEBU 
G= MANAGED_MEM= 
mkdir E:\eu_master\source\intobj 
mkdir E:\eu_master\source\intobj\back 
e:\eu_master\bin\exwc.exe -i ..\include revget.ex 
Incorrect usage. 
Error(E42): Last command making (rev.e) returned a bad status 
Should this file be deleted [Yes/No] ? 

SVN1471 builds properly:

The problem starts happening in SVN1472

SVN1472 notes say :

  • Rewrote the configuration file support.
    It is now greatly expanded. See the docs for details.
    This also meant that the handling of the
    command lines switches was largely redeveloped too.

    This may be a problem in the command-line switch handling.

    bernie
new topic     » goto parent     » topic index » view message » categorize

3. Re: VER 4.0 build error

bernie said...

SVN1471 builds properly:

The problem starts happening in SVN1472

SVN1472 notes say :

  • Rewrote the configuration file support.
    It is now greatly expanded. See the docs for details.
    This also meant that the handling of the
    command lines switches was largely redeveloped too.

    This may be a problem in the command-line switch handling.

    bernie

Bernie,

Thanks for pointing this out. I am not on Windows and building seems to work OK here under Linux. I will be on windows a bit later this evening and I'll sort it out if someone doesn't beat me to it.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

4. Re: VER 4.0 build error

bernie said...

While building SVN1488 on XP I get the following error ...

e:\eu_master\bin\exwc.exe -i ..\include revget.ex 
Incorrect usage. 

It is a bug in the command line handling. I'll work on that now.

However, for now it can be avoided by using svnversion.exe. But it appears that it can't find that program on your system. That program comes when you install SubVersion and it needs to be on your path.

new topic     » goto parent     » topic index » view message » categorize

5. Re: VER 4.0 build error

DerekParnell said...
bernie said...

While building SVN1488 on XP I get the following error ...

e:\eu_master\bin\exwc.exe -i ..\include revget.ex 
Incorrect usage. 

It is a bug in the command line handling. I'll work on that now.

However, for now it can be avoided by using svnversion.exe. But it appears that it can't find that program on your system. That program comes when you install SubVersion and it needs to be on your path.

Thanks Derek:
I'am using the TortoiseSVN Client.
SubVersion is a complete SubVersion System that is why I don't
have it on my XP Home system.

I don't think it is a good idea to require a user
to have SubVersion on their system to build the Euphoria
binaries.
I hope you can fix the code so svnversion.exe is not needed.

new topic     » goto parent     » topic index » view message » categorize

6. Re: VER 4.0 build error

bernie said...

I don't think it is a good idea to require a user to have SubVersion on their system to build the Euphoria binaries.

I hope you can fix the code so svnversion.exe is not needed.

I agree. Can we check the result of the system call to svnversion.exe and if it failed, simply write a rev.ex that says SVN_VERSION = "Unknown" ?

Jeremy

new topic     » goto parent     » topic index » view message » categorize

7. Re: VER 4.0 build error

jeremy said...
bernie said...

I don't think it is a good idea to require a user to have SubVersion on their system to build the Euphoria binaries.

I hope you can fix the code so svnversion.exe is not needed.

I agree. Can we check the result of the system call to svnversion.exe and if it failed, simply write a rev.ex that says SVN_VERSION = "Unknown" ?

Jeremy

We already do this. Actually, if we can't find svnversion, we try to figure out what the version is without it, and then only write unknown if we can't figure it out.

In fact, we originally didn't bother calling svnversion. That was added later, and it is not required.

However, since it is causing problems, maybe we should avoid calling svnversion altogether?

new topic     » goto parent     » topic index » view message » categorize

8. Re: VER 4.0 build error

It should be able to be tried w/o causing an issue. Maybe we need to go back and visit the original problem and make sure it was diagnosed right.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

9. Re: VER 4.0 build error

jeremy said...

It should be able to be tried w/o causing an issue. Maybe we need to go back and visit the original problem and make sure it was diagnosed right.

Jeremy

Could someone explain to me why it is necessary to go through
all the complication to get the SVN number for building a source.

Why can't a simple text file that is updated each time
an addition to the source is committed to the repository

Then when the source is download or updated by a user
this text file will always contain the latest SVN version number
that can be simply read during the end user's compile.

The SVN version should be handle at the repository at the
commit time even if extra steps are required by the developer's
commit NOT during the end users compile.

new topic     » goto parent     » topic index » view message » categorize

10. Re: VER 4.0 build error

bernie said...
jeremy said...

It should be able to be tried w/o causing an issue. Maybe we need to go back and visit the original problem and make sure it was diagnosed right.

Jeremy

Could someone explain to me why it is necessary to go through
all the complication to get the SVN number for building a source.

Why can't a simple text file that is updated each time
an addition to the source is committed to the repository

While the text file may seem easier to you, it would often be out of date, and therefore meaningless. I assure you, the svn way of doing it is definitely simpler for the developers. We just need to figure out what is different about your configuration.

I'd recommend not holding your breath for this (implementing the simple text file solution, that is), as it won't work unless it is automatic.

Matt

new topic     » goto parent     » topic index » view message » categorize

11. Re: VER 4.0 build error

bernie said...

Why can't a simple text file that is updated each time
an addition to the source is committed to the repository

mattlewis said...

While the text file may seem easier to you, it would often be out of date, and therefore meaningless. I assure you, the svn way of doing it is definitely simpler for the developers. We just need to figure out what is different about your configuration.

I'd recommend not holding your breath for this (implementing the simple text file solution, that is), as it won't work unless it is automatic.

Matt

It is actually possible to do this, fully automated, with CVS. I couldn't find an SVN analogue, but perhaps someone with more SVN experience will be able to chip in.

new topic     » goto parent     » topic index » view message » categorize

12. Re: VER 4.0 build error

mattlewis said...
bernie said...
jeremy said...

It should be able to be tried w/o causing an issue. Maybe we need to go back and visit the original problem and make sure it was diagnosed right.

Jeremy

Could someone explain to me why it is necessary to go through
all the complication to get the SVN number for building a source.

Why can't a simple text file that is updated each time
an addition to the source is committed to the repository

While the text file may seem easier to you, it would often be out of date, and therefore meaningless. I assure you, the svn way of doing it is definitely simpler for the developers. We just need to figure out what is different about your configuration.

I'd recommend not holding your breath for this (implementing the simple text file solution, that is), as it won't work unless it is automatic. Matt

Matt:
The problem is caused because revget.ex expects svnversion.exe
to be on a the end users system. That file will not be on any
end user that has source on their system and not the COMPLETE
SUBVERSION SYSTEM on there computer.

If as each developer does a commit on the trunk that developer
could run a special revget after their commit on the trunk and
create a special SVN_version text which would be placed
in the trunk.
The trunk would now contain all the latest files and the
correct SVN_version text file for that trunk and NO REVGET.EX.

Then anytime a developer does commit a SVN_version text file is
replaced; so no matter weather a end user does a update of
his source or downloads the complete source this special
SVN_version text file contain with that source will be valid.

If this problem is not correct now; when the source is
distributed with the binaries no user will be able to build
it without this problem.

new topic     » goto parent     » topic index » view message » categorize

13. Re: VER 4.0 build error

jimcbrown said...

It is actually possible to do this, fully automated, with CVS. I couldn't find an SVN analogue, but perhaps someone with more SVN experience will be able to chip in.

SVN does not have the concept text replacements of $Id$ and friends.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

14. Re: VER 4.0 build error

jeremy said...
jimcbrown said...

It is actually possible to do this, fully automated, with CVS. I couldn't find an SVN analogue, but perhaps someone with more SVN experience will be able to chip in.

SVN does not have the concept text replacements of $Id$ and friends.

Oh... If we had admin rights to our SVN, we could easily add a commit hook to do this, but we do not, so it's not worth mentioning grin

Jeremy

new topic     » goto parent     » topic index » view message » categorize

15. Re: VER 4.0 build error

bernie said...

Matt:
The problem is caused because revget.ex expects svnversion.exe
to be on a the end users system. That file will not be on any
end user that has source on their system and not the COMPLETE
SUBVERSION SYSTEM on there computer.

Looking at the OP, you are wrong.


I'll repeat, WRONG.
The problem is a bug in the way -i is handled. Derek was going to work on fixing this. But this has nothing to do with svnversion.exe

bernie said...


If as each developer does a commit on the trunk that developer
could run a special revget after their commit on the trunk and
create a special SVN_version text which would be placed
in the trunk.

I'm not aware of a way to run an automated script on the client side to do that (and even if it was possible, it'd be an increase in the burden of becoming a dev).

And as Jeremy pointed out, we can't add the hook to the server side (where it'd a) be a lot easier to do and b) work much better than either your proposed system or the current system) because we lack permission to do so.

new topic     » goto parent     » topic index » view message » categorize

16. Re: VER 4.0 build error

bernie said...

The problem is caused because revget.ex expects svnversion.exe
to be on a the end users system. That file will not be on any
end user that has source on their system and not the COMPLETE
SUBVERSION SYSTEM on there computer.

You're incorrect. It tries to use this, and falls back to other methods if this fails. But in your case, revget.ex wasn't even executing.

bernie said...

If as each developer does a commit on the trunk that developer
could run a special revget after their commit on the trunk and
create a special SVN_version text which would be placed
in the trunk.
The trunk would now contain all the latest files and the
correct SVN_version text file for that trunk and NO REVGET.EX.

Yeah, that's not going to happen. revget.ex works pretty well, and wasn't your problem.

bernie said...

If this problem is not correct now; when the source is
distributed with the binaries no user will be able to build
it without this problem.

Not so. We'll be distributing already translated C files, so that all you need is a C compiler to make your own binaries.

Matt

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu