Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » Releasing U++ » U++ as .lib
Re: U++ as .lib [message #11737 is a reply to message #11736] Mon, 24 September 2007 12:14 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1400
Registered: September 2007
Senior Contributor
With something like CMake we could get autogenerated makefiles and MSVC projects. It is reasonably cross platform and a lot easier to use than makefiles.
Re: U++ as .lib [message #11738 is a reply to message #11736] Mon, 24 September 2007 13:00 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
mr_ped wrote on Mon, 24 September 2007 11:54

makefiles are firstly make-dependent.
The system/compiler is issue which can be solved by creating some configuration script and a modular universal makefile. (but it's not a simple thing to do)
Common linux way of building binaries is "configure && make && make install", i.e. the first step is to set up makefile for current system, and to switch on/off modules as you wish it.

So actually you really are reinventing makefiles.

What platforms do you want libs for?
So far mingw+linux+OSX/X11 can work with same (nasty) universal autoconf+makefile.
The other one is needed for MSC.

pkggen.exe looks to me less portable. Some makefile+platforms guru would do this very likely in shorter time.


pkggen.exe is written in U++, source attached. So I believe it should be possible to precompile it as binary for the main platforms.

I agree that CMake or some other make system, if cross-platform/compiler and working, would be a better solution. Yet the configure/make script will look rather ugly, right? Plus, pkggen scans .upp sources for file lists and dependencies. E.g. unless a package is added/removed, nothing has to be modified, neither pkggen.exe nor pkggen.txt. With CMake/configure, I think any modification to a package (add/remove file/dependency) will have to be represented in the script.

The solution IMHO should be a "minimal maintenance" one - one that would allow working on U++ with little regard to the libs. Unless CMake/configure can handle change of filelist, they don't really qualify. A combination of them + .upp scanner could work, though.

Note: I never used CMake/configure, so I might be wrong.
Re: U++ as .lib [message #11743 is a reply to message #11648] Mon, 24 September 2007 18:35 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 801
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor

Good point about .upp files.

IMHO processing the .upp files directly trough (GNU) Makefile string manipulation functions may be possible (but pushing it to the limit - if possible).
Usually pretty often things like perl scripts are used, but that's adding another dependency, and I don't like such idea.
Under common posix/linux shell environment there's always good old sed and similar, but I have no idea how to process such things under bare windows.
Re: U++ as .lib [message #11747 is a reply to message #11743] Mon, 24 September 2007 19:57 Go to previous message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
mr_ped wrote on Mon, 24 September 2007 18:35

Good point about .upp files.

IMHO processing the .upp files directly trough (GNU) Makefile string manipulation functions may be possible (but pushing it to the limit - if possible).
Usually pretty often things like perl scripts are used, but that's adding another dependency, and I don't like such idea.
Under common posix/linux shell environment there's always good old sed and similar, but I have no idea how to process such things under bare windows.


The only thing definitely present on Windows is .bat (batches). But processing strings in batches is true hell (there is replace, but no way to tokenize), and is probably very slow too. There are also .vbs (VB scripts), but these could be disabled due to security risks (high likeness of them being viruses). Other scripts would either require some dependency or have to be compiled to exe - not much better than a dedicated C++ program...

OTOH, why not use a C/C++ program for Windows (amd maybe OSX), and use scripts for Linux/Posix (AFAIK it's next to impossible to precompile a binary to support all distros)? Or write something in plain C/C++, to be compileable with GCC anywhere?


Edit: Thinking of it, pkggen uses the U++ package headers it creates. So, if it's run the first time on Windows like pkggen.exe LINUX POSIX (or whatever other flags are required), the resulting source tree should be all that is required to compile pkggen from source on Linux.

[Updated on: Mon, 24 September 2007 20:56]

Report message to a moderator

Previous Topic: New major release?
Next Topic: Minor releases?
Goto Forum:
  


Current Time: Fri Nov 15 13:42:17 CET 2019

Total time taken to generate the page: 0.01091 seconds