Re: [Flightgear-devel] Windows config.h-mscxx

2010-06-26 Thread Torsten Dreyer
 The files config.h-msvc8 and config.h-msvc90 are necessary for a windows
 build but are now in .gitignore making them inaccessible.
 
 Natively windows has no method to generate these files from the .in files,
 although this is probably possible by installing Perl, and GNU versions  of
 autoconf and automake. - and then learning how to use them !
 
 Could they be put back into the normal distribution path?
It was me, who put them into gitignore because these files are created from 
the respective *.in files during the build. 
Maybe I am wrong, but if these files are created from some other sources, they 
don't belong under source control but the source files do.

If I understand the current setup correctly, a run of autogen.sh and configure 
is required to create the config.h-msvcxx files from the .in files before a 
windows build can run. 

I think it is very unfortunate that some *nix system has to run a configure 
script to generate the files needed for a windows build, put them into the 
source control system to be accessible for windows users.

Maybe Frederic can chime in here with a better idea of how to solve this?

Torsten

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Windows config.h-mscxx

2010-06-26 Thread Frederic Bouvier
  The files config.h-msvc8 and config.h-msvc90 are necessary for a
  windows build but are now in .gitignore making them inaccessible.
  Natively windows has no method to generate these files from the .in
  files, although this is probably possible by installing Perl, and GNU
  versions  of autoconf and automake. - and then learning how to use them !
  
  Could they be put back into the normal distribution path?
 It was me, who put them into gitignore because these files are created
 from the respective *.in files during the build. 
 Maybe I am wrong, but if these files are created from some other
 sources, they don't belong under source control but the source files do.
 
 If I understand the current setup correctly, a run of autogen.sh and
 configure is required to create the config.h-msvcxx files from the .in files
 before a windows build can run. 
 
 I think it is very unfortunate that some *nix system has to run a
 configure script to generate the files needed for a windows build, put 
 them into the source control system to be accessible for windows users.
 
 Maybe Frederic can chime in here with a better idea of how to solve
 this?

I originally included config.h-msvcxx in the autoconf system because there
was a long track record of releases made with the wrong version in these 
files. autoconf is only used to substitute @VERSION@ by the right one.

No need of perl or something else, just copy the .in file and replace 
@VERSION@ by a string, ideally the right version number ;-)

If someone is able to alter the project file to autogen this file with the
good version number, under Windows, without requiring additional tools,
go ahead...

Regards,
-Fred



-- 
Frédéric Bouvier
http://my.fotolia.com/frfoto/  Photo gallery - album photo
http://www.youtube.com/user/fgfred64   Videos


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Windows config.h-mscxx

2010-06-26 Thread Alan Teeder

--
From: Frederic Bouvier fredfgf...@free.fr
Sent: Saturday, June 26, 2010 5:57 PM
To: FlightGear developers discussions 
flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Windows config.h-mscxx

  The files config.h-msvc8 and config.h-msvc90 are necessary for a
  windows build but are now in .gitignore making them inaccessible.
  Natively windows has no method to generate these files from the .in
  files, although this is probably possible by installing Perl, and GNU
  versions  of autoconf and automake. - and then learning how to use them 
  !
 
  Could they be put back into the normal distribution path?
 It was me, who put them into gitignore because these files are created
 from the respective *.in files during the build.
 Maybe I am wrong, but if these files are created from some other
 sources, they don't belong under source control but the source files do.

 If I understand the current setup correctly, a run of autogen.sh and
 configure is required to create the config.h-msvcxx files from the .in 
 files
 before a windows build can run.

 I think it is very unfortunate that some *nix system has to run a
 configure script to generate the files needed for a windows build, put
 them into the source control system to be accessible for windows users.

 Maybe Frederic can chime in here with a better idea of how to solve
 this?

 I originally included config.h-msvcxx in the autoconf system because there
 was a long track record of releases made with the wrong version in these
 files. autoconf is only used to substitute @VERSION@ by the right one.

 No need of perl or something else, just copy the .in file and replace
 @VERSION@ by a string, ideally the right version number ;-)

 If someone is able to alter the project file to autogen this file with the
 good version number, under Windows, without requiring additional tools,
 go ahead...

 Regards,
 -Fred


Fred

Thanks for that. I had just this minute run a diff check on config.h-msc90 
(from my CVS archive) and  config.h-msc90.in

As you say the only difference is that each occurrence of @VERSION@ is 
replaced by 2.0.0. This is exactly the change that has to be made in 
simgear/simgear.h.in before it is copied to simgear.h.

Is there any need for this to be done by all new cloners before compilation? 
It seems to be an unnecessary complication.

All GIT users should be currently working with the same version (2.0.0) in 
both simgear and flightgear. As and when a new version comes about both 
these files can be updated and committed by whoever is responsible for 
raising the issue number.

As an aside I tried to generate config.h-msc90  with cygwin autoconf - but 
it failed with an error at line 799 in file configure.ac.

Alan 


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Windows config.h-mscxx

2010-06-26 Thread Frederic Bouvier

- Alan Teeder a écrit :
 Is there any need for this to be done by all new cloners before
 compilation? 
 It seems to be an unnecessary complication.
 
 All GIT users should be currently working with the same version
 (2.0.0) in both simgear and flightgear. As and when a new version comes about
 both these files can be updated and committed by whoever is responsible for
 raising the issue number.
 
 As an aside I tried to generate config.h-msc90  with cygwin autoconf -
 but it failed with an error at line 799 in file configure.ac.

I forgot to mention I proposed this change in the CVS era before I had 
commit privilege. It's obvious that now I could commit the file with the
correct version number, because I doubt a Linux developer will do it 
spontaneously ;-). 

I am away on vacation now so I can't promise when this will be done, 
but it may be wise to remove the .in files and their reference in 
configure.ac, and remove the target files from .gitignore

-Fred


-- 
Frédéric Bouvier
http://my.fotolia.com/frfoto/  Photo gallery - album photo
http://www.youtube.com/user/fgfred64   Videos


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Windows config.h-mscxx

2010-06-26 Thread Jari Häkkinen
On 6/26/10 7:36 PM, Alan Teeder wrote:
 Is there any need for this to be done by all new cloners before compilation?
 It seems to be an unnecessary complication.

The reason for having autoconf to replace the version string is that
there should only be one place where the version string is set 
(configure.ac or some associated file depending on the build system setup).

(Some) Mac and all(?) linux users use autoconf and there is no issue. I 
suppose the problem of copying the file and changing the string manually 
affects windows and mac xcode (I think) users.

The source file is the .in file and that should be in the repository and 
nothing else.


 All GIT users should be currently working with the same version (2.0.0) in
 both simgear and flightgear. As and when a new version comes about both
 these files can be updated and committed by whoever is responsible for
 raising the issue number.

Well, technically git users are working on 2.x (or 2.0.x or what ever 
the next version will be called). Again, the idea is that the version 
number should only be changed in one place and propagated by the build 
system.

In your case it is a header for MSVC and for other developers the 
version will be propagated to other files. This type of scenario is 
error prone.


Cheers,

Jari

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Windows config.h-mscxx

2010-06-26 Thread Durk Talsma
On Saturday 26 June 2010 07:55:10 pm Frederic Bouvier wrote:
 I forgot to mention I proposed this change in the CVS era before I had
 commit privilege. It's obvious that now I could commit the file with the
 correct version number, because I doubt a Linux developer will do it
 spontaneously ;-).

Unless that Linux Developer also happens to be the release coordinator and is 
properly briefed on the need to do so. :-)

Cheers,
Durk
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel