autotools + MSVC
Hi, This may not be the best list for this, but I'm already subscribed and someone here probably knows the answer. I'm trying to build an autotools in a Cygwin environment, but using MSVC's cl.exe and link.exe. However, this is what I get when I run make: ---begin--- make[1]: Entering directory `//z/parsa/parsa2/src/kernel' cl -DHAVE_CONFIG_H -I. -I. -I../../src/include -GX -TP -I../include-I../com pat -Ie:\qt/include -I../include -I../compat -Ie:\qt/include -capplicationpro ject.cc Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. Command line error D2021 : invalid numeric argument '/Wp,-MD,.deps/applicationpr oject.pp' make[1]: *** [applicationproject.o] Error 2 make[1]: Leaving directory `//z/parsa/parsa2/src/kernel' make: *** [all-recursive] Error 1 ---end--- If I manually run the command line make claims its running, it works! I'm using automake 1.4, autoconf 2.13, make 3.79.1, and MSVC 6.0 SP4. CXX=cl, CXXFLAGS="-GX -TP" I've tried making configure and the Makefile.in's on the NT machine, and on a Linux box that shares the same SMB mount. Doesn't seem to make a difference. --- Geoffrey Wossum [EMAIL PROTECTED]
Re: More an autopackage
Actually, you could probably steal the script stuff from the portable.c file that shows the license agreement. I wouldn't wait for the response (that would break GUI installers), but at least you can cat out the license agreement to the screen... But just displaying the license doesn't have any legal force. The user has to be forced to "click-through". For free software purposes, this isn't a big deal, but it is for commercial software. We're hoping to extend EPM in v3.0 to support sub-packages and other things so that you can utilize more of the RPM/Debian/PKG/DEPOT/INST capabilities. We also have some beta patches that add AIX support (probably go into 2.4), so the list file approach may give you the best bang for the buck, and you won't have to worry so much about dealing with the subtleties of RPM, etc. As far as sub-packages go, it isn't a big deal to make subpackages with epm 2.2. You just make a seperate list file for each package. autopkg could just generate seperate list files, and epm could concentrate on handling the details of the packager. This doesn't help people who want to use epm in isolation. But people using epm in isolation have to manually write list files anyway. - Variable definition in list files (e.g. "$prefix=/dir"), overridden by env or command-line options. I had a .in file that configure was macro substituting to get the same effect. - Better dependency support (version numbers as well as packages) I assume this requires coorperation with the underlying platform packager? --- Geoffrey Wossum [EMAIL PROTECTED]
Re: More an autopackage
I think this need to depend on the configure-generated Makefile will have a very constraining effect on the implementation language: this precludes using ANYTHING that's not installed standard on any of the expected target OSes... That's exactly why configure generates sh-scripts and why libtool IS a shell script. The user will only need autopkg (and Python/Perl/whatever) if they want to build packages. They do not need autopkg and its implementation language if they don't want to do this. You can use GNU m4 or PERL in autoconf and automake, as these are maintainer-only tools. If autopackage is a package-installer tool (i.e. a native package front-end) the choice of implementation language is almost restricted to "/bin/sh" or "/bin/sh" and probably "/bin/sh" :-) I would imagine that 95% of the people using autopkg would be package maintainers. These people probably would install any language required if it made their job as package maintainers easier. There will be some people who want to compile their own stuff, but also want features a packaging system provides, like dependency tracking and uninstall. These people would probably also be willing to install Python or Perl to get the features. --- Geoffrey Wossum [EMAIL PROTECTED]
Re: More an autopackage
Automake can't create all of the spec file. It doesn't have enough information. And, adding the information to Makefile.am does not make sense (because it is global to a package, which Makefile.am really isn't). Also, generating a list of files is not enough. You also need pre- and post- install and uninstall commands. One way to get these is the *_INSTALL variables, which I talked about earlier. I was thinking about this, and I considered another possibility. autopkg would scan the Makefile.am to build a basic specfile, which the developer could then add pre/post install scripts and so forth. This would be analogous to autoscan producing a basic configure.in that the developer then customizes. --- Geoffrey Wossum [EMAIL PROTECTED]
More an autopackage
Hi again, I want to work on the unified front-end to native packaging systems like I posted before, but the bossman doesn't want to wait until that's useable. So the autopackage front-end is going to be YASP (yet another side project) for me. Anyway, here's some of my thoughts about it: 1) written in Python 2) At first, it'll just be a unified front-end to rpm and dpkg and friends. Then, some of the more difficult issues that have been brought up will be tackled, such as package dependencies and automagically deciding the right files and locations for platforms. 3) I think the interface to it will be a file specifying the requirements for the package. Files to include, where to install them, pre and post install scripts, etc. At first, developers just write this file by hand. Even this is a great improvement. Then, automake gets modified to be able to automatically create this spec file. (Is this a good idea?) 4) Is autopackage a good name? 5) I'm really a software developer, not a packaging guy. That's why this seems like such a good idea. I want to write code, not mess with packaging systems. But, I really don't know that much about packaging. So I'll probably need some help with the packaging details. 6) When I get going with Actual Code (TM) (within a couple of weeks), I'll setup a project on sourceforge for this. And finally, thanks to everyone who responded to my initial post. --- Geoffrey Wossum [EMAIL PROTECTED]
Re: OS-sympathetic installation
David, But there seems to be one vital missing component. Way back in the olden days, we needed "make install" to put the product into its final location(s). But these days, many operating systems have their own package-management mechanisms (the word "package" is here overloaded!). My own experience is with the Solaris pkgadd/pkgrm family of commands, but other Oses have other things such as "RPM" etc. You're right, it is missing right now. Has any thought been given to this idea? Yes. And I plan to do something about it. I plan to start on a unified front end to all the packaging systems within a couple of weeks. Then automake can use this front-end to create packages. Later on, more advanced stuff will be done with it, such as automagically figuring out package dependencies and such. There's been several posts concering this type of stuff in the past week (check the archive), and I just posted my plans about 5 minutes ago. --- Geoffrey Wossum [EMAIL PROTECTED]
Re: More an autopackage
Anyway, here's some of my thoughts about it: 1) written in Python Wouldn't Perl5 be a more widely acceptable choice? Considerably so? (Indeed, isn't automake already in Perl? Why choose something different? Especially when that something is considerably less widely installed?) I originally considered Perl5, basically because automake is in Perl (Perl4 to be precise). But this project screams object-oriented, and Perl's OO support is pretty kludgy. I think Larry Wall even says that in Programming Perl. Python's OOP support is much better. Passing self to every method is kindof kludgy, but overall it's much better than Perl's OO. I've never written a large project in Python, but I have in Perl. Another reason I would choose Python ;) In the same vein, I have noticed a shift in the community's preferred scripting language away from Perl towards Python. This said, I would still probably choose Perl over Python for a quick and dirty script. If someone wants to contribute code to the project, but don't know the implementation language, Python is much easier to learn than Perl. I know a large number of programming languages. C, C++, Java, Visual Basic, Perl, Python, LISP, Scheme, Tcl, Fortran, S370/68k/x86/PIC ASM... most languages that have enjoyed significant popularity except for COBOL. And Perl was by far the most difficult to learn. The install base is an important issue. My Solaris, Tru64, and Irix boxes have Perl, but not Python. But they didn't come with Perl out of the box, somebody had to install Perl. So I don't think also installing Python is that big of a deal. And all modern Linux distros include Perl and Python out of the box. No promises. But I could try to have a quick look at Solaris pkgadd/pkgrm issues once you have got started. Thanks. --- Geoffrey Wossum [EMAIL PROTECTED]
Package support (RPM, deb, pkg, kits, etc.)
Hi, I'm interested in platform dependent packaging support, such as RPM and pkg and friends. The autotools book mentions support for these for 1.5, but the CVS code doesn't show any work towards this goal. The TODO file has this as a long term goal, mentioning possibly creating another tool for this functionality. Seeing as how packaging support doesn't seem to be here yet, I would like to work on it. I work on a multiplatform commercial project that was recently switched from Imake to autotools, and platform packaging has always been a pain. I'd rather add support to autotools for this than merely port the old Imake based scripts over. So I have the following questions (some of these I'm sure will trigger drawn out conversations): 1) Is my evalution of automake's current lack of package support correct? 2) Would it be preferable to add all the support into automake, or to create another utility (autopkg?) that would be integrated with automake? 3) What implementation language would be preferred for another tool? I would prefer Perl5, but I am open to suggestions from the community. 4) What should the interface into the packaging support be? autotools are the best software build tools around. With platform packaging support, nobody would ever want to use anything else. --- Geoffrey Wossum [EMAIL PROTECTED]
