Ralf Hemmecke wrote: > > > Structure of build_dir is supposed to parallel structure of src_dir. > > Well, that's the idea and one of the reasons that makes the "target" > directory inside build_dir somewhat superfluous. > > > I am affraid that putting generation of everthing is src/doc is not > > a good idea. > > Wait a minute. I said, I'll create bitmaps, htex, and ht subdirectories > under src/doc. These are source files. To where I generate I didn't mention. > > But yes, the idea was to generate all the files inside src/doc. > I really don't know why you care so much. Isn't the "target" > subdirectory something you finally care about?
1) I had to many times to look at intermediate trash in build directories (not only in FriCAS). So I care if things are easy to find or not. 2) You may consider the patch as "final solution", but in practice problems show up and require changes. So I want things to be manageable. > From what I see in the > toplevel Makefile, installation basically works by copying over the > "target" subdir to the installation location. If you need "target" for > the algebra bootstrap, that's fine, but for most other things I consider > it useless. All the Makefile targets that I have created that start with > "copy-" would actually be targets that should be executed at "make > install" time. > > > I would prefer generation of .ht pages to be in separate directory > > from generating .pht-s and viewports. Basically they use separate > > rules and each involves large number of files, so IMHO keeping them > > separte would more managable. But this is not very strong opinion. > > Generating them into separate subdirs makes the Makefile rules slightly > more complicated. And actually nobody but a machine must manage these > generated files. And if there is need for debugging, they are easily > distinguishable by their file extension. I am affraid we are miscomunicating. This is software, everything is doable with enough effort. The point is to make developement as smooth as possible. Current FriCAS is far from ideal. But I would like to avoid regressing. Size of directories may look like a small thing. But IME both complicated hierarchies with tiny directories and big "universal" directories are problematic. The problems are not big, but the cost of more managable organization is usually small. Again, while problems due to big directories are small they cause distraction exactly at time when distractions are highly undesirable (during debugging). > > If that is problematic for you, then I think that generating > > everything in something like 'src/doc/gen_ht' is better than plain > > 'src/doc' (the idea is that AXIOM book and possible other things can > > go into different subdirectories of 'src/doc'. > > I'll think about that, but out-of-source build already separates sources > from generated files. I don't see a strong reason to create other subdirs. > > > One extra thing: I would like to keep current practice of bundling > > generated .pht-s and viewports with release tarball. More > > precisely, I think it is important to bundle graphic .pht pages and > > viewports. But given that the simplest thing to do is to bundle all > > generated .ht and .pht pages. With directory arrangement in trunk > > this is relatively easy and there is reasonably clear distiction > > between real sources and generated files bundled into release tarball > > (the generated files are in src/paste). And generation of release > > tarball can be done by a simple script (see src/scripts/mkdist.sh). > > From this point of view generated '.ht' files should be in different > > subdirectory from '.ht' files which are sources. > > All we want is "make dist" which would put the respective files into a > predefined location. This is a possibility. But 'mkdist.sh' takes parameters and hence can do more then generating releases. In principle 'make' can do the same, but 'make' is rather weak as a programming language. So I found using a separate script simpler. > > BTW: I noticed curious thing: on my build machine real time for > > 'make all-input' after build in the htdoc branch seem to be 20s > > larger (that 120s versus 100s) than real time in trunk. > > I haven't measured that myself, but note that there is the generation of > the .ht files from .htex and a generation of some of the .help files. > But what exactly means "'make all-input' after build"? I thought that > I've stamped everything so that a remake should cost almost no time. > > Ralf > > -- > You received this message because you are subscribed to the Google Groups > "FriCAS - computer algebra system" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/fricas-devel. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Waldek Hebisch [email protected] -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/groups/opt_out.
